Re: [PHP-DEV] Proposal fo "Code-free constructors declaration"

2019-01-25 Thread Rowan Collins
On Fri, 25 Jan 2019 at 15:37, Levi Morrison  wrote:

>
> If you have any more complex of a need (such as private variables)
> then I think you should write the constructor. The reason is that if
> you have private variables, you need to establish a public API
> contract.
>

Right, which is why I think this is solving a different problem.

The OP was proposing a syntax that would allow you to simplify cases like
"call parent constructor with this constant, then set these 3 properties";
a call-time syntax like this is no use for that.

Regards,
-- 
Rowan Collins
[IMSoP]


Re: [PHP-DEV] Proposal fo "Code-free constructors declaration"

2019-01-25 Thread Levi Morrison
On Fri, Jan 25, 2019 at 4:05 AM Nikita Popov  wrote:
>
> On Fri, Jan 25, 2019 at 11:44 AM Nikita Popov  wrote:
>
> > On Wed, Jan 23, 2019 at 1:33 PM Andrey O Gromov 
> > wrote:
> >
> >> Full description
> >> https://wiki.php.net/rfc/code_free_constructor
> >> Draft realisation
> >> https://github.com/php/php-src/compare/master...rjhdby:constructor
> >>
> >> "Code free" constructor is constructor with only purpose to directly set
> >> object properties from received parameters and, optionally, call parent
> >> constructor.
> >>
> >> Main idea is to move such constructor declaration inside class
> >> declaration.
> >>
> >> Simple example:
> >>
> >> Current syntax
> >> class A extends B{
> >> public $prop;
> >>
> >> public function __construct($prop){
> >> parent::__construct("BlaBla", $prop);
> >> $this->prop = $prop;
> >> }
> >> }
> >>
> >> Proposed syntax
> >> class A($prop) extends B("BlaBla", $prop) {
> >> }
> >>
> >> With respect, Andrey.
> >
> >
> > Two alternatives you might want to consider:
> >
> > * https://wiki.php.net/rfc/automatic_property_initialization => Proposed
> > function public function __construct(int $this->x, int $this->y) {}, which
> > avoids the need for explicit property assignments in the ctor. However, the
> > property still needs to be declared separately.
> >
> > *
> > https://docs.hhvm.com/hack/other-features/constructor-parameter-promotion
> > => Uses public function __construct(public int $x, public int $y) {} to
> > declare properties in-line in the constructor.
> >
> > I think that *if* we want to add some kind of sugar of this type, then I'd
> > strongly prefer the syntax used by Hack than the one proposed here. It
> > makes a lot more sense to me intuitively, probably because the property
> > declarations still looks like normal property declarations, they just occur
> > in-line in the ctor.
> >
> > Nikita
> >
>
> To add to this: While I can totally understand the motivation to avoid the
> property/constructor boilerplate (where the property name needs to be
> repeated four times), I think that this is really solving the wrong
> problem. The problem is the need to have a constructor at all.
>
> Both this RFC and the two alternatives mentioned above really target the
> case of "dumb" constructors that don't really do anything beyond assigning
> properties from ctor arguments. I think that that is better solved by
> adding a first-class syntax for object construction. I have something
> roughly like this in mind:
>
> class Point {
> public int $x;
> public int $y;
> public int $z;
> }
>
> // (syntax just a dummy)
> $origin = new Point { x = 0, y = 0, z = 0 };
>
> Where the object initialization syntax ensures that all properties that
> don't have defaults are initialized. Especially now that we have typed
> properties and it is feasible to have data objects with just public typed
> properties, I think that this is the way to avoid ctor boilerplate, rather
> than making it simpler to write that boilerplate.
>
> Nikita

I support this idea, although I think the `=` should be `=>` like
arrays, or `:` like JSON.

If you have any more complex of a need (such as private variables)
then I think you should write the constructor. The reason is that if
you have private variables, you need to establish a public API
contract.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] New RFC about variables.

2019-01-25 Thread Rowan Collins
On Fri, 25 Jan 2019 at 10:32, Глеб Жуков  wrote:

> Hi, my name is Gleb Zhukov.
>
> In my RFC I want to propose to use a new entities(abstractions), like
> *objects*, *structures* and *data* instead of variables. It gives such
> advatege like a mental division of different, independent entities(objects,
> structures, data) in any language.
>

Hi Gleb!

This sounds a lot like how Perl uses "sigils" for different data types -
$scalar, @array, %hash

The problem with this in a complex language like PHP is that you soon run
out of different characters for the different types you might want to
represent. Note that your example already fails in this regard, because it
suggests "#", which is already used for comments.

When designing a language for the first time, it's an interesting thing to
consider, but in an established language like PHP, it would be very
disruptive, and I don't think it brings that much benefit.

You can get almost the same thing in your own code by naming variables
based on their type (so-called "Hungarian notation").

Regards,
-- 
Rowan Collins
[IMSoP]


Re: [PHP-DEV] Proposal fo "Code-free constructors declaration"

2019-01-25 Thread Rowan Collins
On Fri, 25 Jan 2019 at 11:05, Nikita Popov  wrote:

> class Point {
> public int $x;
> public int $y;
> public int $z;
> }
>
> // (syntax just a dummy)
> $origin = new Point { x = 0, y = 0, z = 0 };
>
> Where the object initialization syntax ensures that all properties that
> don't have defaults are initialized. Especially now that we have typed
> properties and it is feasible to have data objects with just public typed
> properties, I think that this is the way to avoid ctor boilerplate, rather
> than making it simpler to write that boilerplate.
>


The big difference here is that you are making the short-hand the
responsibility of the caller, rather than the definer. I suspect there's a
Venn diagram of use cases where the two features would be useful.

In particular, the call-site syntax you have there would work really well
for a value type, and could go with having full support for that (e.g. have
the resulting object be immutable / copy-on-write); it works less well for
something like dependency injection, where the properties would normally be
private, and you might want to combine the short-hand with some normal
constructor logic.

Regards,
-- 
Rowan Collins
[IMSoP]


Re: [PHP-DEV] New RFC about variables.

2019-01-25 Thread Michał Brzuchalski
Is this a joke?

pt., 25 sty 2019 o 11:32 Глеб Жуков  napisał(a):

> Hi, my name is Gleb Zhukov.
>
> In my RFC I want to propose to use a new entities(abstractions), like
> *objects*, *structures* and *data* instead of variables. It gives such
> advatege like a mental division of different, independent entities(objects,
> structures, data) in any language. For example
>
> //If earlier we were using variables to store, or access objects, data and
> everything else
>
> $object = new SomeClass();
> $array = ['one','two' => 'three'];
> $data = 'string';
>
> //Now we will use special "*object*" entities to store or access objects
> (wich may be defined with # character)
>
> #object = new SomeClass();
>
> //Special "*structure*" entities for arrays or any other structures (wich
> may be defined with * character)
>
> *stucrture = ['one', 'two', 'key' => 'val', 'another_key' =>
> 'another_val'];
>
> //And special "*data*" entities for all data (strings, integers, floats,
> booleans) (wich may be defined with % character)
>
> %string = 'abcde';
> %integer = 123;
> %floating = 1.23;
> %boolean = true;
>
> The remaining types(callables, resources), I suppose, should continue to
> store in variables. New characters for our new entities will be discussed
> further in RFC.
>


-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com


Re: [PHP-DEV] Proposal fo "Code-free constructors declaration"

2019-01-25 Thread Nikita Popov
On Fri, Jan 25, 2019 at 11:44 AM Nikita Popov  wrote:

> On Wed, Jan 23, 2019 at 1:33 PM Andrey O Gromov 
> wrote:
>
>> Full description
>> https://wiki.php.net/rfc/code_free_constructor
>> Draft realisation
>> https://github.com/php/php-src/compare/master...rjhdby:constructor
>>
>> "Code free" constructor is constructor with only purpose to directly set
>> object properties from received parameters and, optionally, call parent
>> constructor.
>>
>> Main idea is to move such constructor declaration inside class
>> declaration.
>>
>> Simple example:
>>
>> Current syntax
>> class A extends B{
>> public $prop;
>>
>> public function __construct($prop){
>> parent::__construct("BlaBla", $prop);
>> $this->prop = $prop;
>> }
>> }
>>
>> Proposed syntax
>> class A($prop) extends B("BlaBla", $prop) {
>> }
>>
>> With respect, Andrey.
>
>
> Two alternatives you might want to consider:
>
> * https://wiki.php.net/rfc/automatic_property_initialization => Proposed
> function public function __construct(int $this->x, int $this->y) {}, which
> avoids the need for explicit property assignments in the ctor. However, the
> property still needs to be declared separately.
>
> *
> https://docs.hhvm.com/hack/other-features/constructor-parameter-promotion
> => Uses public function __construct(public int $x, public int $y) {} to
> declare properties in-line in the constructor.
>
> I think that *if* we want to add some kind of sugar of this type, then I'd
> strongly prefer the syntax used by Hack than the one proposed here. It
> makes a lot more sense to me intuitively, probably because the property
> declarations still looks like normal property declarations, they just occur
> in-line in the ctor.
>
> Nikita
>

To add to this: While I can totally understand the motivation to avoid the
property/constructor boilerplate (where the property name needs to be
repeated four times), I think that this is really solving the wrong
problem. The problem is the need to have a constructor at all.

Both this RFC and the two alternatives mentioned above really target the
case of "dumb" constructors that don't really do anything beyond assigning
properties from ctor arguments. I think that that is better solved by
adding a first-class syntax for object construction. I have something
roughly like this in mind:

class Point {
public int $x;
public int $y;
public int $z;
}

// (syntax just a dummy)
$origin = new Point { x = 0, y = 0, z = 0 };

Where the object initialization syntax ensures that all properties that
don't have defaults are initialized. Especially now that we have typed
properties and it is feasible to have data objects with just public typed
properties, I think that this is the way to avoid ctor boilerplate, rather
than making it simpler to write that boilerplate.

Nikita


Re: [PHP-DEV] Proposal fo "Code-free constructors declaration"

2019-01-25 Thread Nikita Popov
On Wed, Jan 23, 2019 at 1:33 PM Andrey O Gromov  wrote:

> Full description
> https://wiki.php.net/rfc/code_free_constructor
> Draft realisation
> https://github.com/php/php-src/compare/master...rjhdby:constructor
>
> "Code free" constructor is constructor with only purpose to directly set
> object properties from received parameters and, optionally, call parent
> constructor.
>
> Main idea is to move such constructor declaration inside class
> declaration.
>
> Simple example:
>
> Current syntax
> class A extends B{
> public $prop;
>
> public function __construct($prop){
> parent::__construct("BlaBla", $prop);
> $this->prop = $prop;
> }
> }
>
> Proposed syntax
> class A($prop) extends B("BlaBla", $prop) {
> }
>
> With respect, Andrey.


Two alternatives you might want to consider:

* https://wiki.php.net/rfc/automatic_property_initialization => Proposed
function public function __construct(int $this->x, int $this->y) {}, which
avoids the need for explicit property assignments in the ctor. However, the
property still needs to be declared separately.

* https://docs.hhvm.com/hack/other-features/constructor-parameter-promotion
=> Uses public function __construct(public int $x, public int $y) {} to
declare properties in-line in the constructor.

I think that *if* we want to add some kind of sugar of this type, then I'd
strongly prefer the syntax used by Hack than the one proposed here. It
makes a lot more sense to me intuitively, probably because the property
declarations still looks like normal property declarations, they just occur
in-line in the ctor.

Nikita


[PHP-DEV] New RFC about variables.

2019-01-25 Thread Глеб Жуков
Hi, my name is Gleb Zhukov.

In my RFC I want to propose to use a new entities(abstractions), like
*objects*, *structures* and *data* instead of variables. It gives such
advatege like a mental division of different, independent entities(objects,
structures, data) in any language. For example

//If earlier we were using variables to store, or access objects, data and
everything else

$object = new SomeClass();
$array = ['one','two' => 'three'];
$data = 'string';

//Now we will use special "*object*" entities to store or access objects
(wich may be defined with # character)

#object = new SomeClass();

//Special "*structure*" entities for arrays or any other structures (wich
may be defined with * character)

*stucrture = ['one', 'two', 'key' => 'val', 'another_key' => 'another_val'];

//And special "*data*" entities for all data (strings, integers, floats,
booleans) (wich may be defined with % character)

%string = 'abcde';
%integer = 123;
%floating = 1.23;
%boolean = true;

The remaining types(callables, resources), I suppose, should continue to
store in variables. New characters for our new entities will be discussed
further in RFC.