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.
And, regarding 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 ?
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).
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.
2010/3/27 Toorion <toor...@gmail.com>:
> On 03/27/2010 07:23 PM, Martin Jansen wrote:
>>
>> On 27.03.10 17:02, Toorion wrote:
>>>
>>> $myLongNameObject = new MyLongNameObject();
>>> $myLongNameObject->property1 = '11111';
>>> $myLongNameObject->property2 = '22222';
>>> $myLongNameObject->property3 = '33333';
>>> $myLongNameObject->property4 = '44444';
>>> $myLongNameObject->property5 = '55555';
>>
>> [...]
>>
>>> $MyLongNameObject = new MyLongNameObject() {
>>> $property1 = '1111';
>>> $property2 = '2222';
>>> $property3 = '4444';
>>> $property4 = '5555';
>>> }
>>
>> What exactly do you gain with the new syntax?
>
> Readable code. Simplicity of developing, debugging.
> So, I write short example. Actually I work with long UI code (DOM, PHP-ExtJS
> implementation, more other new UI solution) and that code look like this:
>
> $grid = new ExtGridPanel();
> $grid->store = new JsonStore();
> $grid->store->autodestroy = true;
> $grid->store->url = 'plain.xml';
> $grid->store->reader = new JesonReader();
> $grid->store->reader->record = 'plant';
> $grid->store->reader->fields = array();
> $i = 0;
> $grid->store->reader->fields[$i] = new StoreField();
> $grid->store->reader->fields[$i]->name = 'common';
> $grid->store->reader->fields[$i]->type = 'string';
> $grid->store->reader->fields[++$i] = new StoreField();
> $grid->store->reader->fields[$i]->name = 'botanical';
> $grid->store->reader->fields[$i]->type = 'string';
> $grid->store->reader->fields[++$i] = new StoreField();
> $grid->store->reader->fields[$i]->name = 'light';
> $grid->store->reader->fields[++$i] = new StoreField();
> $grid->store->reader->fields[$i]->name = 'price';
> $grid->store->reader->fields[$i]->type = 'float';
> $grid->store->reader->fields[++$i] = new StoreField();
> $grid->store->reader->fields[$i]->name = 'availDate';
> $grid->store->reader->fields[$i]->type = 'date';
> $grid->store->reader->fields[$i]->mapping = 'availability';
> $grid->store->reader->fields[$i]->dateFormat = 'm/d/Y';
> $grid->store->reader->sortinfo = new stdClass();
> $grid->store->reader->sortinfo->field = 'common';
> $grid->store->reader->sortinfo->direction = 'ASC';
> $grid->renderTo = 'editor-grid',
> $grid->width = 600;
> $grid->height = 300;
> $grid->autoExpandColumn = 'common';
> $grid->title = 'Edit plants';
> $grid->frame = true;
> $grid->tbar = new ExtTBar();
> .... more code with setting of tbar properties....
> $grid->items = array();
> $i = 0;
> $grid->items[$i] = new GridItem();
> $grid->items[$i]->id = 'common';
> $grid->items[$i]->header = 'Common name';
> $grid->items[$i]->dataIndex = 'common';
> $grid->items[$i]->width = 220;
> $grid->items[$i]->editor = new GridColumnEditor();
> ... more properties of GridColumnEditor ....
> ... more properties of next few items ....
>
> So, as you can see, this code (small part of PHP-ExtJS UI implementation)
> absolute unreadable. Yes, I can use variables like this:
>
> $r = new JsonReader();
> $r->record = 'plant';
> $r->fields = array();
> $i = 0;
> $r->fields[$i] = new StoreField();
> $r->fields[$i]->name = 'common';
> $r->fields[$i]->type = 'string';
> $r->fields[++$i] = new StoreField();
> $r->fields[$i]->name = 'botanical';
> $r->fields[$i]->type = 'string';
>
> And:
>
> $grid->store->reader = $r;
>
> But it is not a good programming style - Who know what is it $r?, $a, $b,
> $c.... Usually I put $reader, $store, etc, But when in code few $readers,
> $stores - It become more difficult to identify variable.
> With proposal shorthand setting I can write more compressive:
>
> $fields[] = new StoreField() { $name = 'common'; $type = 'string' }
>
> Instead of
>
> $i = 0;
> $grid->store->reader->fields[$i] = new StoreField();
> $grid->store->reader->fields[$i]->name = 'common';
> $grid->store->reader->fields[$i]->type = 'string';
>
> So, this sample I show - very short ;) In many cases for describe UI
> required more code, with DOM and CSS structures. Maybe it is not for PHP 5.3
> and 6.0, but I sure in future some possibility become necessary.
> Actually I didn't understood, what for needed unnamed Object initialization
> new ObjectName( unnamed parameter, unnamed parameter) if usually in
> construct we did:
>
> function __construct( $param1, $param2, $param3 ) {
> $this->attribute1 = $param1;
> $this->attribute2 = $param2;
> $this->attribute3 = $param3;
> }
>
> 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.
>
>
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
С уважением,
Виктор
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
