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
