What about a magic interface instead of a new base class, in a similar vein to the existing Array Access and Serializable interfaces. NonDynamic perhaps?
On Mon, May 21, 2012 at 5:09 PM, Tom Boutell <t...@punkave.com> wrote: > Rasmus, isn't your concern about the impact of dynamic property > support on developers who don't actually use it a nonissue in 5.4, > where properties that aren't dynamic are stored as a flat array? > > On Mon, May 21, 2012 at 4:52 PM, Rasmus Schultz <ras...@mindplay.dk> wrote: >> Adding/removing properties at runtime is great if you want obscure, >> unmaintainable code and don't think an IDE is useful. >> >> So to make my previous statement more precise, dynamic properties are >> not widely used in respectable modern codebases, and is generally >> something a reputable developer would frown upon. Yes, some codebases >> (e.g. Drupal) rely on this extensively, but modern frameworks >> generally do not - in fact, they often take measures to ensure that >> exceptions are thrown if you try to access a property that has not >> been formally defined. >> >> For that matter, most ORMs (a typical example of where dynamic >> properties would come in handy) don't rely on dynamic properties >> either - they rely on __get() and __set() and store the actual values >> in a single property, as an array. So even for highly dynamic >> components in modern frameworks, this is not a feature that is often >> used. >> >> Drupal-development aside, and perhaps some XOOPS-development back in >> the dark ages, I can't actually recall when I've used dynamic >> properties. >> >> I suddenly realize why certain heavily-used classes in the Yii >> framework have obscure property-names like $_m and $_p ... they're >> trying to save memory. Not really logical that you should have to >> compromise legible code in favor of saving memory. >> >> Makes me wonder if this issue could be addressed, killing two birds >> with one stone. Since the dynamic aspect is an inconvenience to many >> developers, and since it causes memory-overhead whether they make use >> of this feature or not, how about introducing a non-dynamic >> alternative base-class that actually throws if you access properties >> that have not been defined? >> >> This wouldn't change the way PHP objects work by default, but would >> lighten the memory-overhead in a lot of modern frameworks, and >> possibly speed up property-access too, since you can have a flat >> look-up table for class-properties; and could eliminate the need for >> an "object" or "component" base-class in frameworks... >> >> >> On Mon, May 21, 2012 at 2:55 PM, Stas Malyshev <smalys...@sugarcrm.com> >> wrote: >>> Hi! >>> >>>> How come it's necessary to store the property-names of every property >>>> in every object? For properties that have been defined in classes, why >>>> can't they be stored in a more efficient manner? (using lookup tables) >>> >>> No because you can add and remove properties freely at runtime. >>> >>>> I know the nature of PHP is dynamic, and I know that dynamic >>>> properties would have to be stored in a key/value form internally... >>>> but if you look at modern PHP software, dynamic properties is actually >>>> something very few people use. >>> >>> This is not true. >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
