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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
