# Proposal: shorthand object property setting syntax.

- Thread: https://externals.io/message/47655
- Original archive: https://news-web.php.net/php.internals/47655
- Started by Toorion on 2010-03-27T16:02:40+00:00
- Messages: 15
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #47655 — Toorion — 2010-03-27T16:02:40+00:00

URL: https://externals.io/message/47655#47655

Very often (for example when work with dom or UI object) setting plenty 
of object properties is require. At this time we has not a lot options.
Standard way looks very dirty and be reason of more copy-paste-work.

Reproduce code:
---------------
$myLongNameObject = new MyLongNameObject();
$myLongNameObject->property1 = '11111';
$myLongNameObject->property2 = '22222';
$myLongNameObject->property3 = '33333';
$myLongNameObject->property4 = '44444';
$myLongNameObject->property5 = '55555';

Or worse case:
$myLongNameObject = new MyLongNameObject(); // Proxy pattern
$myLongNameObject->property1 = '11111';
$myLongNameObject->property2 = '22222';
$myLongNameObject->property3 = '33333';
$myLongNameObject->insideObject = new InsideObject();
$myLongNameObject->insideObject->propertyOne   = '1111';
$myLongNameObject->insideObject->propertyTwo   = '2222';
$myLongNameObject->insideObject->propertyThree = '3334';
$myLongNameObject->insideObject->propertyFour  = '4444';

So, apparently, that is not good. We can use special constructor code 
and array like parameter of constructor like this:
$MyLongNameObject = new MyLongNameObject( array(
     'property1' = '1111',
     'property2' = '2222',
     .....
));
But it's look like crutch and can't extended with IDE. Match better if 
we can set multiple properties in one time something like this:

$MyLongNameObject = new MyLongNameObject() {
     $property1 = '1111';
     $property2 = '2222';
     $property3 = '4444';
     $property4 = '5555';
}

And (for multiple setting properties for exists object):

$MyLongNameObject = new MyLongNameObject();
$MyLongNameObject->{
     $propertyOne   = '1111';
     $propertyTwo   = '2222';
     $propertyThree = '3333';
     $propertyFour  = '4444';
}

So, this way can help in many cases with initialization long OOP 
structures and economy lot of time for programming, debugging and 
refactoring code.

---

## #47656 — Martin Jansen — 2010-03-27T16:23:19+00:00

URL: https://externals.io/message/47655#47656 · In reply to: #47655

> $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?  You don't save LOC with
it (actually it requires one more line) and you still have to type all
the property names.  Using an editor with code completion one can
produce the code in the current syntax pretty quickly after all.

- Martin

---

## #47657 — Stefan Marr — 2010-03-27T16:29:27+00:00

URL: https://externals.io/message/47655#47657 · In reply to: #47656

> 
> > […]
> 
> [...]
> 
> > […]
> 
> What exactly do you gain with the new syntax?  You don't save LOC with
> it (actually it requires one more line) and you still have to type all
> the property names.  Using an editor with code completion one can
> produce the code in the current syntax pretty quickly after all.
LOC isn't a very useful metric anyway...

However, the proposal reminds me of Pascal's 'with'-construct:

http://en.wikipedia.org/wiki/Pascal_(programming_language)


new(pointertob);
 
with pointertob^ do
begin
  a := 10;
  b := 'A';
  c := nil
end;


> 
> - Martin
> 
> -- 
> 
> 
> 

-- 
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525

---

## #47658 — Martin Jansen — 2010-03-27T16:39:26+00:00

URL: https://externals.io/message/47655#47658 · In reply to: #47657

> 
> 
> 
> > […]
> LOC isn't a very useful metric anyway...

Of course.  I was primarily referring to Toorion's assertion that the
new syntax is less time-consuming.  In doing so I assumed that typing N
lines of code consume less time than typing N+1. :)

> However, the proposal reminds me of Pascal's 'with'-construct:
> 
> new(pointertob);
>  
> with pointertob^ do
> begin
>   a := 10;
>   b := 'A';
>   c := nil
> end;

Can one do something like "b := this.a"?  This sounds like a huge can of
worms to me.

- Martin

---

## #47659 — Stefan Marr — 2010-03-27T16:57:30+00:00

URL: https://externals.io/message/47655#47659 · In reply to: #47658

> > […]
> 
> Can one do something like "b := this.a"?  This sounds like a huge can of
> worms to me.
Ehm, I don't see what might be problematic with "b := this.a".

However, I did not mean to propose it, I just thought I mention it.
Think there was also a similar discussion (with respect to something similar to 'with') a while back.

But since PHP requires you to write your '$this->' everywhere, such a construct does not feel very much inline with this rest of the language which is explicit.

Back to the original proposal, from my point of view, source code is meant to be read, and repetition is handled easily by the human brain, a bit of alignment with whitespace and voilà...  


Best regards
Stefan

> 
> - Martin
> 
> -- 
> 
> 
> 

-- 
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525

---

## #47660 — johannes@php.net — 2010-03-27T17:09:28+00:00

URL: https://externals.io/message/47655#47660 · In reply to: #47655

> Very often (for example when work with dom or UI object) setting plenty 
> of object properties is require. At this time we has not a lot options.
> Standard way looks very dirty and be reason of more copy-paste-work.
> 
> Reproduce code:
> ---------------
> $myLongNameObject = new MyLongNameObject();
> $myLongNameObject->property1 = '11111';
> $myLongNameObject->property2 = '22222';
> $myLongNameObject->property3 = '33333';
> $myLongNameObject->property4 = '44444';
> $myLongNameObject->property5 = '55555';

You can always use a (temporary) alias to shorten things

$myLongNameObject = new MyLongNameObject();
$t = $myLongNameObject;
$t->property1 = '11111';
$t->property2 = '22222';
$t->property3 = '33333';
$t->property4 = '44444';
$t->property5 = '55555';
unset($t);

> Or worse case:
> $myLongNameObject = new MyLongNameObject(); // Proxy pattern
> $myLongNameObject->insideObject = new InsideObject();
> $myLongNameObject->insideObject->propertyOne   = '1111';
> $myLongNameObject->insideObject->propertyTwo   = '2222';
> $myLongNameObject->insideObject->propertyThree = '3334';
> $myLongNameObject->insideObject->propertyFour  = '4444';

$t = $myLongNameObject->insideObject;
$t->propertyOne = '11111';
$t->propertyTwo = '22222';


> So, apparently, that is not good. We can use special constructor code 
> and array like parameter of constructor like this:
> $MyLongNameObject = new MyLongNameObject( array(
>      'property1' = '1111',
>      'property2' = '2222',
>      .....
> ));

Better API design would be my first choice, details depend on the
specific case.

> But it's look like crutch and can't extended with IDE. Match better if 
> we can set multiple properties in one time something like this:
> 
> $MyLongNameObject = new MyLongNameObject() {
>      $property1 = '1111';
>      $property2 = '2222';
>      $property3 = '4444';
>      $property4 = '5555';
> }

That won't work easily as there's a conflict between other local
variables. So this might only work with very specific expressions,which
is then mostly useless. Syntax-wise it /could/  work like this:

with ($MyLongNameObject) {
    ->property1 = '1111';
    ->property2 = '2222';
}

but there's no big benefit over an alias but way more confusion with a
new syntax, a new keyword, ...

No need to add something special here.

johannes

---

## #47661 — Pierre Joye — 2010-03-27T17:21:31+00:00

URL: https://externals.io/message/47655#47661 · In reply to: #47660

2010/3/27 Johannes Schlüter <johannes@php.net>:

>  Syntax-wise it /could/  work like this:
>
> with ($MyLongNameObject) {
>    ->property1 = '1111';
>    ->property2 = '2222';
> }
>
> but there's no big benefit over an alias but way more confusion with a
> new syntax, a new keyword, ...

This syntax is well known in many languages. So if we ever introduce
something similar, I'd to choose that one over any other.

-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

---

## #47662 — Toorion — 2010-03-27T17:57:14+00:00

URL: https://externals.io/message/47655#47662 · In reply to: #47656

> 
> > […]
>
> [...]
>
> > […]
>
> 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.

---

## #47663 — Toorion — 2010-03-27T18:16:29+00:00

URL: https://externals.io/message/47655#47663 · In reply to: #47660

> You can always use a (temporary) alias to shorten things
>
> $myLongNameObject = new MyLongNameObject();
> $t = $myLongNameObject;
> $t->property1 = '11111';
> $t->property2 = '22222';
> $t->property3 = '33333';
> $t->property4 = '44444';
> $t->property5 = '55555';
> unset($t);
Yes, I use this and I should in any way (with shorthand syntax too), 
but, how I describe one post before - It help not a much. This just a 
short sample of code. In big code anyway no readable.

> That won't work easily as there's a conflict between other local
> variables. So this might only work with very specific expressions,which
> is then mostly useless. Syntax-wise it /could/  work like this:
>
> with ($MyLongNameObject) {
>      ->property1 = '1111';
>      ->property2 = '2222';
> }
Ok, I just describe idea, but not an implementation.


> but there's no big benefit over an alias but way more confusion with a
> new syntax, a new keyword, ...
Unfortunately for UI plenty of code is necessary. And in future more web 
application will be use Dynamic UI. And it is tendency - use server side 
generator for client side dynamic UI - here is many advantage -
No needed work directly with DOM+CSS+HTML+JavaScript, which distinguish 
from one browser to other, It let change UI to user - from 
administrative panel (with modify UI implementation) - in CMS, for 
example... So, I found this idea in JavaScript, when possible to 
initialize object like { attribute1 = value1, attribute2 = value2 } and 
it is very helpful. But much better use PHP UI framework, which produce 
HTML,CSS,JavaScript code, than write lot of code in many environment. 
Plus PHP OOP model much better than others.

---

## #47664 — Stan Vassilev — 2010-03-27T19:38:08+00:00

URL: https://externals.io/message/47655#47664 · In reply to: #47663

Hi,

There is another solution to this problem, which is sort-of-on-the-table, 
and it's named parameters:

$myLongNameObject = new MyLongNameObject(
    'property1' => '11111',
    'property2' => '22222',
    'property3' => '33333',
    'property4' => '44444',
    'property5' => '55555',
);

With proper update, code hinting for named parameters could be introduced in 
IDEs in order not to end up slower than the current syntax.

It also solves other issues and doesn't suffer from the scope resolution 
problems "with() {}" suffers from.

Regards,
Stan Vassilev

---

## #47665 — Bharat Nagwani — 2010-03-27T19:59:33+00:00

URL: https://externals.io/message/47655#47665 · In reply to: #47664

I might have missed earlier emails. How about this?

$myLongNameObject = new myLongNameObject {
    property1: '11111',
    property2: '22222',
    property3: '33333',
    property4: '44444',
    property5: '55555',
};

Can we avoid the new as well like in Javascript?

$myLongNameObject = {
    property3: 'xyz',
    property4: 'abc',
    property5: 5,
    property6: {
        a: 1
    }
};

---

## #47666 — Davey Shafik — 2010-03-28T01:14:36+00:00

URL: https://externals.io/message/47655#47666 · In reply to: #47665

> I might have missed earlier emails. How about this?
> 
> $myLongNameObject = new myLongNameObject {
>    property1: '11111',
>    property2: '22222',
>    property3: '33333',
>    property4: '44444',
>    property5: '55555',
> };
> 
> Can we avoid the new as well like in Javascript?
> 
> $myLongNameObject = {
>    property3: 'xyz',
>    property4: 'abc',
>    property5: 5,
>    property6: {
>        a: 1
>    }
> };

Except that "new myLongNameObject" and { } are not the same, your latter syntax — just as in JavaScript — would
yield an anonymous object, essentially the same as "new stdClass" :)

You could just as easily do:

$myLongNameObject = (object) array (
	'property3' => 'xyz',
	'property4' => 'abc',
	'property5' => (object) array (
		'a' => 1
	)
);

---

## #47667 — Stan Vassilev — 2010-03-28T10:36:43+00:00

URL: https://externals.io/message/47655#47667 · In reply to: #47666

Hi,

There is another solution to this problem, which is sort-of-on-the-table,
and it's named parameters:

$myLongNameObject = new MyLongNameObject(
    'property1' => '11111',
    'property2' => '22222',
    'property3' => '33333',
    'property4' => '44444',
    'property5' => '55555',
);

With proper update, code hinting for named parameters could be introduced in
IDEs in order not to end up slower than the current syntax.

It also solves other issues and doesn't suffer from the scope resolution
problems "with() {}" suffers from.

Regards,
Stan Vassilev

---

## #47671 — Victor Bolshov — 2010-03-29T05:19:27+00:00

URL: https://externals.io/message/47655#47671 · In reply to: #47662

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 <toorion@gmail.com>:
> 
> > […]
>
> 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.
>
>
>
>
>
>
>
> --
> 
> 
>
>



-- 
С уважением,
Виктор

---

## #48035 — Toorion — 2010-04-21T11:20:22+00:00

URL: https://externals.io/message/47655#48035 · In reply to: #47671

Sorry for long delay...


> 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.



> > […]
> 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.