Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47671
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.225 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=CObojsbf3PFDQ1sWmXsICbfJl+kHLcxGlHbps7FyIvi0SWGeBSf6Sf3SDABTspPla6
         h2S8rb5hQOQF8LtzZGdNKTmgg6MEKNkItgL/JQAXtWHPosOYsybUyFKP4dwkZjF6fBvO
         k1jrMLQR0gOr8yg6bqnB6wG1pdsXsdQ39C6Gc=
MIME-Version: 1.0
In-Reply-To: <AD.16.22155.1074EAB4@pb1.pair.com>
References: <A5.33.20638.32C2EAB4@pb1.pair.com>
	 <4BAE30F7.5090004@divbyzero.net> <AD.16.22155.1074EAB4@pb1.pair.com>
Date: Mon, 29 Mar 2010 09:19:27 +0400
Message-ID: <d1d50abe1003282219s66a0c4ageca4479af19ccde6@mail.gmail.com>
To: internals@lists.php.net
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Proposal: shorthand object property setting syntax.
From: crocodile2u@gmail.com (Victor Bolshov)

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 =3D { y: "z" }; ), shorthand syntax for
arrays ( x =3D ["y", "z"] ). When creating a Ext.Datagrid in Javascript,
I have never seen constructs like " grid.store.reader.fields[++i] =3D ".
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 =3D new ObectName() { $attr1 =3D 'value', $attr2 =3D 'value' );
> That we can set any value of object and don't needed to make decision whi=
ch 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 =3D 'a
result of complex calculations'; } }

What value should "attr1" be assigned after we've done $instance =3D new
ObectName() { $attr1 =3D 'value', $attr2 =3D '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 <toorion@gmail.com>:
> On 03/27/2010 07:23 PM, Martin Jansen wrote:
>>
>> On 27.03.10 17:02, Toorion wrote:
>>>
>>> $myLongNameObject =3D new MyLongNameObject();
>>> $myLongNameObject->property1 =3D '11111';
>>> $myLongNameObject->property2 =3D '22222';
>>> $myLongNameObject->property3 =3D '33333';
>>> $myLongNameObject->property4 =3D '44444';
>>> $myLongNameObject->property5 =3D '55555';
>>
>> [...]
>>
>>> $MyLongNameObject =3D new MyLongNameObject() {
>>> =9A =9A $property1 =3D '1111';
>>> =9A =9A $property2 =3D '2222';
>>> =9A =9A $property3 =3D '4444';
>>> =9A =9A $property4 =3D '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-Ex=
tJS
> implementation, more other new UI solution) and that code look like this:
>
> $grid =3D new ExtGridPanel();
> $grid->store =3D new JsonStore();
> $grid->store->autodestroy =3D true;
> $grid->store->url =3D 'plain.xml';
> $grid->store->reader =3D new JesonReader();
> $grid->store->reader->record =3D 'plant';
> $grid->store->reader->fields =3D array();
> $i =3D 0;
> $grid->store->reader->fields[$i] =3D new StoreField();
> $grid->store->reader->fields[$i]->name =3D 'common';
> $grid->store->reader->fields[$i]->type =3D 'string';
> $grid->store->reader->fields[++$i] =3D new StoreField();
> $grid->store->reader->fields[$i]->name =3D 'botanical';
> $grid->store->reader->fields[$i]->type =3D 'string';
> $grid->store->reader->fields[++$i] =3D new StoreField();
> $grid->store->reader->fields[$i]->name =3D 'light';
> $grid->store->reader->fields[++$i] =3D new StoreField();
> $grid->store->reader->fields[$i]->name =3D 'price';
> $grid->store->reader->fields[$i]->type =3D 'float';
> $grid->store->reader->fields[++$i] =3D new StoreField();
> $grid->store->reader->fields[$i]->name =3D 'availDate';
> $grid->store->reader->fields[$i]->type =3D 'date';
> $grid->store->reader->fields[$i]->mapping =3D 'availability';
> $grid->store->reader->fields[$i]->dateFormat =3D 'm/d/Y';
> $grid->store->reader->sortinfo =3D new stdClass();
> $grid->store->reader->sortinfo->field =3D 'common';
> $grid->store->reader->sortinfo->direction =3D 'ASC';
> $grid->renderTo =3D 'editor-grid',
> $grid->width =3D 600;
> $grid->height =3D 300;
> $grid->autoExpandColumn =3D 'common';
> $grid->title =3D 'Edit plants';
> $grid->frame =3D true;
> $grid->tbar =3D new ExtTBar();
> .... more code with setting of tbar properties....
> $grid->items =3D array();
> $i =3D 0;
> $grid->items[$i] =3D new GridItem();
> $grid->items[$i]->id =3D 'common';
> $grid->items[$i]->header =3D 'Common name';
> $grid->items[$i]->dataIndex =3D 'common';
> $grid->items[$i]->width =3D 220;
> $grid->items[$i]->editor =3D 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 =3D new JsonReader();
> $r->record =3D 'plant';
> $r->fields =3D array();
> $i =3D 0;
> $r->fields[$i] =3D new StoreField();
> $r->fields[$i]->name =3D 'common';
> $r->fields[$i]->type =3D 'string';
> $r->fields[++$i] =3D new StoreField();
> $r->fields[$i]->name =3D 'botanical';
> $r->fields[$i]->type =3D 'string';
>
> And:
>
> $grid->store->reader =3D $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[] =3D new StoreField() { $name =3D 'common'; $type =3D 'string' }
>
> Instead of
>
> $i =3D 0;
> $grid->store->reader->fields[$i] =3D new StoreField();
> $grid->store->reader->fields[$i]->name =3D 'common';
> $grid->store->reader->fields[$i]->type =3D '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 initializati=
on
> new ObjectName( unnamed parameter, unnamed parameter) if usually in
> construct we did:
>
> function __construct( $param1, $param2, $param3 ) {
> =9A $this->attribute1 =3D $param1;
> =9A $this->attribute2 =3D $param2;
> =9A $this->attribute3 =3D $param3;
> }
>
> Much better if we can join attributes directly from object initialization=
.
> $instance =3D new ObectName() { $attr1 =3D 'value', $attr2 =3D 'value' );
> That we can set any value of object and don't needed to make decision whi=
ch
> of attributes is important and which not.
>
>
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



--=20
=F3 =D5=D7=C1=D6=C5=CE=C9=C5=CD,
=F7=C9=CB=D4=CF=D2