Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60638
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain punkave.com designates 209.85.213.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADqTB_hGRRM901SZWME1qeyiLorZLg+rRs4ZTWpAnr8C-SPxJw@mail.gmail.com>
References: <CADqTB_g+3HBb8qBBS989dedUNnock-SpjRY770C4No4dGyLQTw@mail.gmail.com>
	<4FBA8FB0.80104@sugarcrm.com>
	<CADqTB_hGRRM901SZWME1qeyiLorZLg+rRs4ZTWpAnr8C-SPxJw@mail.gmail.com>
Date: Mon, 21 May 2012 17:09:17 -0400
Message-ID: <CAORXhGL_10p38WAOdr9RngXbEKhLTL6Bj4d8p=VEV6Wb7=tuxQ@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] memory usage ouchy
From: tom@punkave.com (Tom Boutell)

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 <rasmus@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 <smalyshev@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