Re: MidCOM and its further adaption to new Midgard versions - AKA Midgard core quality

Torben Nehmer <[email protected]> wrote:


	Hi again, 

I will go back to the beginning as we need some constructive conclusion.

> Large parts of the Midgard core, *including* the new parts that have been
> written within the last 6 months, are undocumented, both in terms of their
> specification and their actual API (both on a C level and on their language
> bindings). In addition to this, many of the enchantments done are very isolated
> pieces of "this could be a good thing here", they don't fit into a (not actually
> existing) grand scheme and forced me to create hundreds, if not thousands of
> lines of glue code to bring them up to the OO standards I provide to my authors.

1. What should be done on midgard-php extension level to make midgard-php 
be closer to OO standards while being completely midcom unaware?
This is about exceptions made for language bindings , so I would like to know details. 
In other words , what is *really* missing in midgard-php extension what makes those
thousand lines absolutely necessary?

2. Should I add optional parameter to object constructor?
( I am not sure right now how this will work due to zend's zval initialization ) 

3. Should I get parent class for all inherited subclasses' methods inside extension or 
drop this once and for all,  and make caller ( on php level ) responsible for getting parent class?

> Just to name a *few* examples as they come to my mind:
> 
> - - QB-APIs, which still produce notices on empty(!) resultsets

I am again bit confused due to some misunderstanding. I reviewed some parts of 
code during the weekend and 1.8 release ( this one you mentioned ) doesn't produce 
such notices. 

I also removed it from stable branch.

> - - QB calls which just fail when you pass them null (at least they don't segfault
>   anymore).

As above , it only exists in 1.7.3
1.7.4 is postponed due to not confirmed (100%) issue with midcom's root topic and prefix.

> - - An mgdschema file format, which provides tons of features to you, given you
>   can get hold of one of the core guys so that he cen tell you about it.

As I wrote earlier , this is documented since some time , I also updated docs yesterday.

> - - Date handling in the schema, which is unflexible and actually broke full
>   backwards compatiblity by deprecating UNIX timestamps replacing them by ISO
>   timestamps everywhere (not just on date fields you explicitly declare). My
>   recommendation to have more then one date type to handle this was ignored.

This will be ridiculous to write mRFC about this right now.
Please , put your +1/-1 here.

I need to change internal TIMESTAMP type which is DATETIME in fact anyway.

> - - The neccessity to get_by_(gu)id instead of just using the constructor of the
>   DB class (like in DBA).

Question number 2.

> - - No schema parsing in config-test, essentially shooting down your server in
>   case you have an error in your schema when trying to restart. Especially great
>   for production environments. <irony> At least we now have an occasional error
>   message before a SIG_ABORT here, not just a SIG_SEGFAULT, guess I should be
>   grateful.</irony>

As I wrote earlier, schema is parsed when php module is loaded. I can do *nothing" there 
to change Apache's behaviour.
 
> The existing documentation (like the MgdSchema or QB API in the Wiki) is - to
> say it defensivly) mostly useless, it omits most cavets that are in all those
> classes.

There is a note , that that documentation may change in a future.
It's changing. 

Piotras