Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:60643 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 64119 invoked from network); 21 May 2012 22:02:54 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 May 2012 22:02:54 -0000 Authentication-Results: pb1.pair.com smtp.mail=dmgx.michael@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=dmgx.michael@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.182 as permitted sender) X-PHP-List-Original-Sender: dmgx.michael@gmail.com X-Host-Fingerprint: 209.85.212.182 mail-wi0-f182.google.com Received: from [209.85.212.182] ([209.85.212.182:42646] helo=mail-wi0-f182.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3E/C8-16352-C8BBABF4 for ; Mon, 21 May 2012 18:02:53 -0400 Received: by wibhm6 with SMTP id hm6so2475643wib.11 for ; Mon, 21 May 2012 15:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=sAv6rLussFl7OlZ/VUxJw9GNJr20euNXswsPNonebIs=; b=rBw00t6Gyn/aAmy/MNWFcd6Nt54075X+ZcLD0xRoRwH5p6K9bYIdK5getNwIwCNgya e5dya2JghqhogFA1MEQxv8JTe96nAnaAn1Yz8UK+PegrDp0b2k7T5mczQRyfQ7JnNSJJ T++qM9thX7+b/yiYoMcXWZwmGKYdWRzDCJ1cTtbc/Uc3H3FPHQLT1zpjiwsb9fpFTVra ddlAVZRPgsKVFN6pQkyFNiwFjXJVl1cBwgoMfvw15JrRtQCGZ6i7kBH8WNGzr3srQEPy /od1r/zQg6TZM0L/kH3c6Q1+IgC8f3gNeZOB7t6PKYQeZgOOPiS2LTD9So18kdHO99ft SwBw== MIME-Version: 1.0 Received: by 10.180.109.197 with SMTP id hu5mr28737603wib.8.1337637769479; Mon, 21 May 2012 15:02:49 -0700 (PDT) Received: by 10.216.202.16 with HTTP; Mon, 21 May 2012 15:02:49 -0700 (PDT) In-Reply-To: References: <4FBA8FB0.80104@sugarcrm.com> Date: Mon, 21 May 2012 18:02:49 -0400 Message-ID: To: PHP Internals Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PHP-DEV] memory usage ouchy From: dmgx.michael@gmail.com (Michael Morris) 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 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 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 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 >