Document Object.php behaviour (pseudo-statics, overloaded getters)

[ischommer]

Its very hard to understand the Object->stat() and Object->addStaticVars() behaviour at the moment, probably only sam really knows whats going on there. this should be at least documented in PHPDoc, but bonus points for adding a highlevel overview on doc.ss.com ;)

i think some examples contrasting PHP-default and silverstripe static handling could help a lot - e.g. show how static inheritance/aggregation in subclasses works in silverstripe.

[sminnee]

I've had a look at this: there's a lot of unnecessary quirks in the static handling.

I'm in the middle of cleaning everything up so that the various means of setting static variables operate in the same way as much as possible.

Specifically:

• $myObj->set_stat('var') will set MyClass::$var as long as MyClass:$var is explicitly declared.
• But, if MyClass::$var is inherited from ParentClass::$var, and not explicitly declared, then Object::$statics[] will need to be used to store the data. But, rather than Object::$statics[] being treated as a cache, it will be treated as creating the 'static property slots' that PHP didn't create itself on subclasses.
• Object::addStaticVars() will simply make repeated calls to $myObj->set_stat().

[ischommer]

we should also make sure that different datatypes work as expected - especially (nested) array. e.g., with set_stat() you currently can't do unset(MyClass::$arrlevel1?level2?). at the moment addStaticVars() applies array_merge, we need an optional $override flag (or should this actually be the default behaviour? we could let the developer do any merging on his own before doing set_stat())

[ischommer]

I've added some unit tests in r64311, but lots of them are still failing - perhaps because of wrong assumptions, perhaps because of borked static handling. The tests are by no means full coverage, but its a start. Sam, I think you're the only one who can untangle this, and write up some documentation :)