Proposal: shorthand object property setting syntax. View as Markdown

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

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:

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

--

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

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