Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:48035 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 69307 invoked from network); 21 Apr 2010 11:20:30 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Apr 2010 11:20:30 -0000 X-Host-Fingerprint: 79.165.172.25 unknown Received: from [79.165.172.25] ([79.165.172.25:15260] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 61/31-63467-C7FDECB4 for ; Wed, 21 Apr 2010 07:20:29 -0400 Message-ID: <61.31.63467.C7FDECB4@pb1.pair.com> To: internals@lists.php.net Date: Wed, 21 Apr 2010 15:20:22 +0400 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 References: <4BAE30F7.5090004@divbyzero.net> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 79.165.172.25 Subject: Re: [PHP-DEV] Proposal: shorthand object property setting syntax. From: toorion@gmail.com (Toorion) Sorry for long delay... On 03/29/2010 09:19 AM, Victor Bolshov wrote: > Toorion, I suggest *not* your code becomes unreadable because of PHP > limitations but because of you application architecture limitations. > > I see from your example that you're building a Ext.JS datagrid. And, > what is done in the example, is writing in PHP what should be written > in JavaScript. ExtJS requires much code to be written, but when you > write it in JS - it is more convenient to than in PHP: in JS you have > shorthand syntax for objects ( x = { y: "z" }; ), shorthand syntax for > arrays ( x = ["y", "z"] ). When creating a Ext.Datagrid in Javascript, > I have never seen constructs like " grid.store.reader.fields[++i] = ". > To my mind, when you need a PHP backend for a Javascript-datagrid, the > only thing you need in PHP - is a possibility to answer to the > datagrid HTTP-queries in a way that a grid can understand. It is just example, one of plenty. I use it, because try to migrate ExtGWT to php. But any of UI required some kind of code - for PHP-QT or GTK-PHP... Yep, You can say "PHP - only for web server, not for application or integrated client-side frameworks"... So, I have no argument for this. >> Much better if we can join attributes directly from object initialization. >> $instance = new ObectName() { $attr1 = 'value', $attr2 = 'value' ); >> That we can set any value of object and don't needed to make decision which of attributes is important and which not. > I dont know much of PHP internal structure but I can see a conflict in > this syntax: what if in a user-defined __construct() method, there > already is an assignment for $this->attr1 and $this->attr2 ? Yes, but Database functions works like this - if we use mysql_fetch_object() - this function created a object instance, then, assign properties from query, then run __construct() > Example: class ObectName { function __construct() { $this->attr1 = 'a > result of complex calculations'; } } > What value should "attr1" be assigned after we've done $instance = new > ObectName() { $attr1 = 'value', $attr2 = 'value' ); ? Should an error > be raised? What about access modifiers? Should there be a possibility > to access private/protected properties with the new syntax? (If so, it > would certainly break encapsulation and introduce mess). My mind it should work like XXX_fetch_object() functions... Assigning properties _before_ run instance. > In the end, I could only mention that the above does not have a > relation to named parameters (Stan Vassilev talks about them in the > further discussion). Personally, I think, named parameters might be a > useful addition to the language. So, I agree, it can be alternative of my proposal.