Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Rowan Collins]

On Sun, 23 Sep 2018 at 22:48, Nikita Popov  wrote:

>
> There might be a compromise here, which is to only perform a ctor
> initialization check and forbid explicit unset()s if the class does not use
> property accessors (i.e. does not define __get). This allows the lazy
> initialization pattern but is stricter for everything else. (Possibly __get
> in subclasses would also count.)
>

Hm, that's an interesting suggestion, but I think it might get a bit
complicated and confusing.

There's also the paradoxical fact that you can implement __get() to make
your classes *stricter*: public function __get($prop) { throw new
\LogicException("Attempt to access non-existent property $prop"); }

I think I'd prefer to leave the unset() behaviour in, and then:
a) come up with a better mechanism for lazy-initialisation
and b) come up with a way for classes to opt out of having *any* dynamic
property manipulation (no unset, no reads or writes to undeclared
properties)

I might start a thread to bikeshed an appropriate mechanism for (b) because
it's something I've wanted for a long time.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Nikita Popov]

On Sun, Sep 23, 2018 at 10:08 PM Rowan Collins 
wrote:

> On 23/09/2018 19:41, Claude Pache wrote:
> >> 3) Object properties may be type hinted and the class author has until
> the end
> >> of the constructor to make sure they're fulfilled, otherwise TypeError
> on the
> >> spot (what I'm proposing).
> > Just to be sure you don’t miss the herd that this elephant is concealing:
> >
> > In addition, you *must* forbid unset() on those properties...
>
>
> We "must" forbid this IF we aim to guarantee that the object never has
> uninitialised properties; but the current consensus is that we can't
> make such a guarantee without changing a lot of other parts of the
> language.
>
> There are strong feelings that unset should be available for use in
> lazy-initialisation hacks, so this is likely to remain one of the
> back-doors which will let elephants in, unless and until someone comes
> up with a replacement for that hack.
>

There might be a compromise here, which is to only perform a ctor
initialization check and forbid explicit unset()s if the class does not use
property accessors (i.e. does not define __get). This allows the lazy
initialization pattern but is stricter for everything else. (Possibly __get
in subclasses would also count.)

Nikita

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Rowan Collins]

On 23/09/2018 21:50, Christoph M. Becker wrote:

In my opinion, explicitly *declared* properties should not be
unsettable.  We don't allow to undefine constants, functions, classes
etc. either.  Adding and removing other properties could still be allowed.



While I agree, I think that's a somewhat separate discussion: right now, 
you can unset() a declared property, and that is handled differently 
from setting it to null. Weird though it is, there is widely-used code 
which actively relies on this fact, so it's not something we can just "fix".


The solution might be some way of marking a class as "completely 
specified" - no dynamic properties may be added, no declared properties 
may be unset; but like I say, that's a separate discussion.


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Rowan Collins]

On 23/09/2018 19:31, David Rodrigues wrote:

Em dom, 23 de set de 2018 às 13:09, Larry Garfield 
escreveu:


3) Object properties may be type hinted and the class author has until the
end
of the constructor to make sure they're fulfilled, otherwise TypeError on
the
spot (what I'm proposing).


Item 3 could not be enough, for instance:

<<<
class Example {
 public /* string */ $string;
 public function __construct() { static:: stringParameter
($this->string); }
 public static function stringParameter(string $string) {}
}

new Example;

It will fail because __construct() uses an uninitialized non-nullable
property.



Yes, there are various cases where checking at the end of the 
constructor is not enough. The general consensus is that we can't catch 
all of them without major changes to the language, but can catch some of 
the more common scenarios earlier than the current implementation does.




Maybe it should throw a new Exception like UninitializedPropertyException
when you try to read a uninitialized property like this case.



That's exactly what the current implementation will do, and what Larry's 
proposed addition would continue doing in cases where it can't be 
spotted at a "checkpoint" like the end of the constructor.



Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Christoph M. Becker]

On 23.09.2018 at 22:07, Rowan Collins wrote:

> On 23/09/2018 19:41, Claude Pache wrote:
>>
>>> 3) Object properties may be type hinted and the class author has
>>> until the end
>>> of the constructor to make sure they're fulfilled, otherwise
>>> TypeError on the
>>> spot (what I'm proposing).
>> Just to be sure you don’t miss the herd that this elephant is concealing:
>>
>> In addition, you *must* forbid unset() on those properties...
> 
> We "must" forbid this IF we aim to guarantee that the object never has
> uninitialised properties; but the current consensus is that we can't
> make such a guarantee without changing a lot of other parts of the
> language.
> 
> There are strong feelings that unset should be available for use in
> lazy-initialisation hacks, so this is likely to remain one of the
> back-doors which will let elephants in, unless and until someone comes
> up with a replacement for that hack.

In my opinion, explicitly *declared* properties should not be
unsettable.  We don't allow to undefine constants, functions, classes
etc. either.  Adding and removing other properties could still be allowed.

-- 
Christoph M. Becker

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

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Robert Korulczyk]

> Just to be sure you don’t miss the herd that this elephant is concealing:
> 
> In addition, you *must* forbid unset() on those properties...


Shouldn't we delegate the whole problem to object type resolving and make it 
more strict? Right now properties are not guaranteed at all - you can
have `Foo` class with `$bar` property, but it does not mean that instance of 
`Foo` will actually have this property. The current implementation of
typed properties seems to be pretty consistent with this. Type check gives you 
nothing as far as the object's properties are concerned.

But if `$foo instanceof Foo` or `function (Foo $foo)` will test that `$foo`:

1. is an instance of `Foo`,
2. has all properties defined in `Foo`,
3. all typehinted properties are initialized,

then the problem will basically disappear - you can protect yourself from 
propagating uninitialized object by typehints or type checks (which you
would probably do anyway). And you still can create an uninitialized object for 
lazy initialization or whatever you want.


--

Regards,
Robert Korulczyk

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

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Rowan Collins]

On 23/09/2018 19:41, Claude Pache wrote:

3) Object properties may be type hinted and the class author has until the end
of the constructor to make sure they're fulfilled, otherwise TypeError on the
spot (what I'm proposing).

Just to be sure you don’t miss the herd that this elephant is concealing:

In addition, you *must* forbid unset() on those properties...



We "must" forbid this IF we aim to guarantee that the object never has 
uninitialised properties; but the current consensus is that we can't 
make such a guarantee without changing a lot of other parts of the language.


There are strong feelings that unset should be available for use in 
lazy-initialisation hacks, so this is likely to remain one of the 
back-doors which will let elephants in, unless and until someone comes 
up with a replacement for that hack.


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Lester Caine]

Wrong reply button :(

On 23/09/2018 07:18, Rasmus Schultz wrote:

That is the entire point of the elephant analogy: that knowing what can

get in doesn't necessarily mean knowing what is already inside - BUT,
knowing what can get in may still useful in itself.

I understood that, and I disagree - just knowing what can get in is not
useful or interesting in itself. It's not even a new language feature - you
can already achieve the same with a simple setter. It's just new syntax.

The only reason it's interesting to control what can get inside with type
hints, is to enable the language to do something new - something it
couldn't already do, which is to guarantee that the type enforces it's own
state specification.

I understood the analogy, and I don't agree.


In other words it's yet another bodge to add strict typing without 
properly addressing the real problem. Adding 'types' to properties only 
covers the properties that are supplied via that interface? I think that 
is what is being proposed here? Internally the object may have other 
variables that depend on the supplied properties, or be populated from 
another interface such as a database in my case. THOSE variables need to 
be managed in the same way as properties, and magic code like setters or 
PROPER handling of variables is needed to ensure that the variables are 
suitable TO initialize a variable. All these little patches to making 
PHP strict STILL need all of the old code to validate that the data is 
actually usable!


PLEASE can we get back to making variables manage their own VALIDITY 
rather than just some arbitrary concept of type!


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Claude Pache]

> 
> 3) Object properties may be type hinted and the class author has until the 
> end 
> of the constructor to make sure they're fulfilled, otherwise TypeError on the 
> spot (what I'm proposing).

Just to be sure you don’t miss the herd that this elephant is concealing:

In addition, you *must* forbid unset() on those properties...

—Claude

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[David Rodrigues]

Em dom, 23 de set de 2018 às 13:09, Larry Garfield 
escreveu:

> 3) Object properties may be type hinted and the class author has until the
> end
> of the constructor to make sure they're fulfilled, otherwise TypeError on
> the
> spot (what I'm proposing).
>

Item 3 could not be enough, for instance:

<<<
class Example {
public /* string */ $string;
public function __construct() { static:: stringParameter
($this->string); }
public static function stringParameter(string $string) {}
}

new Example;
>>>

It will fail because __construct() uses an uninitialized non-nullable
property.

Maybe it should throw a new Exception like UninitializedPropertyException
when you try to read a uninitialized property like this case.



-- 
David Rodrigues

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Larry Garfield]

On Sunday, September 23, 2018 1:18:02 AM CDT Rasmus Schultz wrote:
> > That is the entire point of the elephant analogy: that knowing what can
> 
> get in doesn't necessarily mean knowing what is already inside - BUT,
> knowing what can get in may still useful in itself.
> 
> I understood that, and I disagree - just knowing what can get in is not
> useful or interesting in itself. It's not even a new language feature - you
> can already achieve the same with a simple setter. It's just new syntax.
> 
> The only reason it's interesting to control what can get inside with type
> hints, is to enable the language to do something new - something it
> couldn't already do, which is to guarantee that the type enforces it's own
> state specification.
> 
> I understood the analogy, and I don't agree.

You previously listed this as an example of problematic code:

class Test {
public string $b;
}

$b = 'foo';
$test = new Test();

And I agree, that's problematic, just not as show-stopping as you seem to feel 
it is.  Which is why I suggested adding a post-constructor-validation-check, 
in which case the above code would fail with a TypeError on the last line (new 
Test()), since it reached the end of the constructor without fulfilling its 
property validation requirements.  Because that is, in the end, the best we 
can do without radical changes to how the language works.

Basically, we have 3 options:

1) Object properties may not ever be type hinted except as nullable, which is 
kinda useless.

2) Object properties may be type hinted but a sloppy class author may still 
leave them undefined/null if they're careless, which is the RFC today.  (How 
much of a problem you think this is depends on how sloppy you expect class 
authors to be.)

3) Object properties may be type hinted and the class author has until the end 
of the constructor to make sure they're fulfilled, otherwise TypeError on the 
spot (what I'm proposing).

If option 3 is insufficient, please explain why.  You have yet to comment on 
that, just say the current RFC is awful.  If adding the extra checks is 
insufficient, offer an alternative.  I cannot think of one that doesn't 
involve adopting Rust's type system.  (Which would be kinda cool, but also 
horribly impractical to do within the next decade.)

--Larry Garfield

signature.asc
Description: This is a digitally signed message part.

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Rasmus Schultz]

> That is the entire point of the elephant analogy: that knowing what can
get in doesn't necessarily mean knowing what is already inside - BUT,
knowing what can get in may still useful in itself.

I understood that, and I disagree - just knowing what can get in is not
useful or interesting in itself. It's not even a new language feature - you
can already achieve the same with a simple setter. It's just new syntax.

The only reason it's interesting to control what can get inside with type
hints, is to enable the language to do something new - something it
couldn't already do, which is to guarantee that the type enforces it's own
state specification.

I understood the analogy, and I don't agree.


On Sun, Sep 23, 2018, 00:42 Rowan Collins  wrote:

> On 22 September 2018 20:32:04 BST, Rasmus Schultz 
> wrote:
> >if you read my last post (especially the last part) carefully, you'll
> >see
> >why this elephant analogy is incomplete.
> >
> >the issue is not whether or not something gets in - it's much more far
> >reaching than that.
> >
> >the issue is, once something gets in, can you even be sure that that
> >something is what it claims to be?
>
> That is the entire point of the elephant analogy: that knowing what can
> get in doesn't necessarily mean knowing what is already inside - BUT,
> knowing what can get in may still useful in itself.
>
> The positions being expressed are therefore, roughly:
>
> a) That it's not the job of this feature to prove what is inside, only to
> guard the door. (That is, that the current implementation is sufficient.)
>
> b) That it is vital to always know what is inside, regardless of how it
> got there. (That is, that we must prevent all mechanisms where the value is
> uninitialised.)
>
> c) That there will always be some ways for the wrong thing to end up
> inside, but that we can add checks at key moments to see if that's
> happened. (That is, that we should detect uninitialised values
> automatically at the end of the constructor, and in similar places, but
> that there well be other ways that uninitialised values can come about.)
>
> In your last message, you seemed to be accepting position c - that not all
> scenarios could be prevented, but that the common case of the constructor
> should be checked. That is the same position Larry is suggesting, so I'm
> not sure why you seem keen to disagree with him.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Rowan Collins]

On 22 September 2018 20:32:04 BST, Rasmus Schultz  wrote:
>if you read my last post (especially the last part) carefully, you'll
>see
>why this elephant analogy is incomplete.
>
>the issue is not whether or not something gets in - it's much more far
>reaching than that.
>
>the issue is, once something gets in, can you even be sure that that
>something is what it claims to be?

That is the entire point of the elephant analogy: that knowing what can get in 
doesn't necessarily mean knowing what is already inside - BUT, knowing what can 
get in may still useful in itself.

The positions being expressed are therefore, roughly:

a) That it's not the job of this feature to prove what is inside, only to guard 
the door. (That is, that the current implementation is sufficient.)

b) That it is vital to always know what is inside, regardless of how it got 
there. (That is, that we must prevent all mechanisms where the value is 
uninitialised.)

c) That there will always be some ways for the wrong thing to end up inside, 
but that we can add checks at key moments to see if that's happened. (That is, 
that we should detect uninitialised values automatically at the end of the 
constructor, and in similar places, but that there well be other ways that 
uninitialised values can come about.)

In your last message, you seemed to be accepting position c - that not all 
scenarios could be prevented, but that the common case of the constructor 
should be checked. That is the same position Larry is suggesting, so I'm not 
sure why you seem keen to disagree with him.

Regards,

-- 
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Larry Garfield]

On Saturday, September 22, 2018 2:32:04 PM CDT Rasmus Schultz wrote:
> Larry,
> 
> this wasn't aimed at "you" personally, I'm just using the proverbial "you",
> as in "not me".
> 
> if you read my last post (especially the last part) carefully, you'll see
> why this elephant analogy is incomplete.
> 
> the issue is not whether or not something gets in - it's much more far
> reaching than that.
> 
> the issue is, once something gets in, can you even be sure that that
> something is what it claims to be?

.. Yes?

> at the moment you can't, and that's a serious issue - type hints appear to
> provide some guarantees that in fact aren't provided at all. it's
> confusing, and the explanations are more complex than they need to be.
> 
> (and I guess that's generally an issue in very dynamic languages, but type
> hints are supposed to provide a means to improve on these problems where it
> makes sense - not make the problems worse.)

Do you have a code sample to explain what you mean?  At the moment I really 
have a hard time envisioning what the pitfall is, especially if we were to add 
checkpoint validity checks.

What's the code that would appear safe but really isn't?  Please show us, 
because I don't know what it is.

--Larry Garfield

signature.asc
Description: This is a digitally signed message part.

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Rasmus Schultz]

Larry,

this wasn't aimed at "you" personally, I'm just using the proverbial "you",
as in "not me".

if you read my last post (especially the last part) carefully, you'll see
why this elephant analogy is incomplete.

the issue is not whether or not something gets in - it's much more far
reaching than that.

the issue is, once something gets in, can you even be sure that that
something is what it claims to be?

at the moment you can't, and that's a serious issue - type hints appear to
provide some guarantees that in fact aren't provided at all. it's
confusing, and the explanations are more complex than they need to be.

(and I guess that's generally an issue in very dynamic languages, but type
hints are supposed to provide a means to improve on these problems where it
makes sense - not make the problems worse.)

On Sat, Sep 22, 2018, 20:32 Larry Garfield  wrote:

> Rasmus: Please be careful when you refer to "you" as wanting or doing
> something.  I had no part in the patch design or implementation beyond
> saying
> "yay!" a few times on the list/twitter.  "I" don't want a particular
> engine
> pseudo-type (uninitialized); I honestly don't care about that level of
> implementation detail.  I am only trying to offer suggestions for how to
> tighten the guarantees further without violating the basic facts of how
> PHP
> works.
>
> On Saturday, September 22, 2018 12:12:48 PM CDT Rowan Collins wrote:
> > On 22/09/2018 11:15, Rasmus Schultz wrote:
> > >> That is, it doesn't assert that a value IS a given type, but that it
> can
> > >> only be SET TO a given type.
> > >
> > > That is literally the same thing - if it can only be set to a given
> > > type, it can only BE a given type.
> >
> > Consider this analogy: if I build a house with a standard, human-sized
> > door, I cannot walk an elephant through that door; however, if the
> > elephant was already there, I could build the house around it. So, the
> > assertion that "no elephant can get in through that door" is not the
> > same as the assertion "there is no elephant inside that house". If
> > you're interested in protecting your house from roaming elephants, the
> > small door is probably sufficient for your needs; if you want to know
> > that when you walk into a house, there is no elephant inside, you need
> > other assurances.
> >
> > What Larry is pointing out is that Levi and Marco are happy to make the
> > door elephant-proof (prevent nulls being assigned to the properties);
> > whereas you and I are looking for a stronger guarantee that there will
> > never be an elephant inside (that the object will not be in an invalid
> > state).
>
> LOL.  Rowan, I love that analogy.  It expresses the problem space very
> well.
>
> > > I don't think that, and I don't expect that - I'm not suggesting we
> > > enforce
> > > anything statically, I'm merely suggesting that a constructor needs to
> > > satisfy the constraints specified by the class.
> >
> > If you read carefully, that's exactly what Larry's proposal below
> requires.
> >
> > >> To wit, could we add an engine check to scan an object and make sure
> its
> > >> objects are all type valid right-now (viz, nothing is unitialized),
> and
> > >> then call it on selected actions automatically and allow users to call
> > >> it at arbitrary times if they are doing more esoteric things?
> > >
> > > In my opinion, this is a solution to the problem we created when we
> > > decided
> > > every property should internally be annotated with an "initialized"
> > > boolean
> > > property - you have all this extra state that wasn't part of the
> > > specification of the class itself, and now you have to deal with that
> > > state.
> > >
> > > In my opinion, tracking this extra state *during the constructor call*
> is
> > > acceptable and necessary in a scripting language like PHP - I never
> > > asked for static type-checking, I'm merely asking for this check to be
> > > built-into the language and performed at run-time when you exit the
> > > constructor, e.g. at the last moment where you can feasibly perform
> > > this check.
> >
> > I'm not sure if you've misunderstood Larry's proposal, or are just
> > agreeing with it: the sentence you quote says "add an engine check" and
> > "call it on selected actions automatically"; and you ask for it to be
> > "built-into the language and performed at run-time"; you mention it
> > happening "when you exit the constructor", and just below the part you
> >
> > quote, so does he:
> > > * on __construct() exit.
> > > * on __wakeup() exit.
> > > * Possibly other similar checkpoints.
> >
> > The key compromise, however, is that this still doesn't guarantee that
> > there is no elephant in the house: there will be ways to create an
> > object that don't go through the constructor, so won't trigger this
> > check; and ways to manipulate an object that will put it into an invalid
> > state. Not to mention that inside the constructor, $this will be usable
> > as a normal object, unlike in 

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Larry Garfield]

Rasmus: Please be careful when you refer to "you" as wanting or doing 
something.  I had no part in the patch design or implementation beyond saying 
"yay!" a few times on the list/twitter.  "I" don't want a particular engine 
pseudo-type (uninitialized); I honestly don't care about that level of 
implementation detail.  I am only trying to offer suggestions for how to 
tighten the guarantees further without violating the basic facts of how PHP 
works.

On Saturday, September 22, 2018 12:12:48 PM CDT Rowan Collins wrote:
> On 22/09/2018 11:15, Rasmus Schultz wrote:
> >> That is, it doesn't assert that a value IS a given type, but that it can
> >> only be SET TO a given type.
> > 
> > That is literally the same thing - if it can only be set to a given
> > type, it can only BE a given type.
> 
> Consider this analogy: if I build a house with a standard, human-sized
> door, I cannot walk an elephant through that door; however, if the
> elephant was already there, I could build the house around it. So, the
> assertion that "no elephant can get in through that door" is not the
> same as the assertion "there is no elephant inside that house". If
> you're interested in protecting your house from roaming elephants, the
> small door is probably sufficient for your needs; if you want to know
> that when you walk into a house, there is no elephant inside, you need
> other assurances.
> 
> What Larry is pointing out is that Levi and Marco are happy to make the
> door elephant-proof (prevent nulls being assigned to the properties);
> whereas you and I are looking for a stronger guarantee that there will
> never be an elephant inside (that the object will not be in an invalid
> state).

LOL.  Rowan, I love that analogy.  It expresses the problem space very well.

> > I don't think that, and I don't expect that - I'm not suggesting we
> > enforce
> > anything statically, I'm merely suggesting that a constructor needs to
> > satisfy the constraints specified by the class.
> 
> If you read carefully, that's exactly what Larry's proposal below requires.
> 
> >> To wit, could we add an engine check to scan an object and make sure its
> >> objects are all type valid right-now (viz, nothing is unitialized), and
> >> then call it on selected actions automatically and allow users to call
> >> it at arbitrary times if they are doing more esoteric things?
> > 
> > In my opinion, this is a solution to the problem we created when we
> > decided
> > every property should internally be annotated with an "initialized"
> > boolean
> > property - you have all this extra state that wasn't part of the
> > specification of the class itself, and now you have to deal with that
> > state.
> > 
> > In my opinion, tracking this extra state *during the constructor call* is
> > acceptable and necessary in a scripting language like PHP - I never
> > asked for static type-checking, I'm merely asking for this check to be
> > built-into the language and performed at run-time when you exit the
> > constructor, e.g. at the last moment where you can feasibly perform
> > this check.
> 
> I'm not sure if you've misunderstood Larry's proposal, or are just
> agreeing with it: the sentence you quote says "add an engine check" and
> "call it on selected actions automatically"; and you ask for it to be
> "built-into the language and performed at run-time"; you mention it
> happening "when you exit the constructor", and just below the part you
> 
> quote, so does he:
> > * on __construct() exit.
> > * on __wakeup() exit.
> > * Possibly other similar checkpoints.
> 
> The key compromise, however, is that this still doesn't guarantee that
> there is no elephant in the house: there will be ways to create an
> object that don't go through the constructor, so won't trigger this
> check; and ways to manipulate an object that will put it into an invalid
> state. Not to mention that inside the constructor, $this will be usable
> as a normal object, unlike in a true 2-phase initialisation system like
> Swift's.
> 
> In short, we will still need runtime errors for attempting to read an
> uninitialized property, but they will be much less likely to happen
> accidentally and show up a long way from their cause.
> 
> 
> I would be interested to hear if there are any use cases that this would
> break - a static factory method can defer as much initialisation as
> needed to the constructor, and cases where the constructor is bypassed
> will also bypass the check.
> 
> Regards,

Yes, Rowan has it exactly.  To continue the analogy, I'm proposing that, once 
the house is built, you take a moment to look inside and say "Holy crap, 
there's an elephant in here!"

In more code terms, this is an extremely common pattern in PHP today (using 
the post-RFC syntax):

class Doer {

  protected Processor $processor;

  public function __construct(Processor $p) {
$this->processor = $p;
  }
  // ...
}

This code is obviously valid, because while there is a moment at which the 

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Rowan Collins]

On 22/09/2018 11:15, Rasmus Schultz wrote:

That is, it doesn't assert that a value IS a given type, but that it can only
be SET TO a given type.

That is literally the same thing - if it can only be set to a given
type, it can only BE a given type.



Consider this analogy: if I build a house with a standard, human-sized 
door, I cannot walk an elephant through that door; however, if the 
elephant was already there, I could build the house around it. So, the 
assertion that "no elephant can get in through that door" is not the 
same as the assertion "there is no elephant inside that house". If 
you're interested in protecting your house from roaming elephants, the 
small door is probably sufficient for your needs; if you want to know 
that when you walk into a house, there is no elephant inside, you need 
other assurances.


What Larry is pointing out is that Levi and Marco are happy to make the 
door elephant-proof (prevent nulls being assigned to the properties); 
whereas you and I are looking for a stronger guarantee that there will 
never be an elephant inside (that the object will not be in an invalid 
state).




I don't think that, and I don't expect that - I'm not suggesting we enforce
anything statically, I'm merely suggesting that a constructor needs to satisfy
the constraints specified by the class.


If you read carefully, that's exactly what Larry's proposal below requires.



To wit, could we add an engine check to scan an object and make sure its
objects are all type valid right-now (viz, nothing is unitialized), and then
call it on selected actions automatically and allow users to call it at
arbitrary times if they are doing more esoteric things?

In my opinion, this is a solution to the problem we created when we decided
every property should internally be annotated with an "initialized" boolean
property - you have all this extra state that wasn't part of the specification
of the class itself, and now you have to deal with that state.

In my opinion, tracking this extra state *during the constructor call* is
acceptable and necessary in a scripting language like PHP - I never
asked for static type-checking, I'm merely asking for this check to be
built-into the language and performed at run-time when you exit the
constructor, e.g. at the last moment where you can feasibly perform
this check.


I'm not sure if you've misunderstood Larry's proposal, or are just 
agreeing with it: the sentence you quote says "add an engine check" and 
"call it on selected actions automatically"; and you ask for it to be 
"built-into the language and performed at run-time"; you mention it 
happening "when you exit the constructor", and just below the part you 
quote, so does he:



* on __construct() exit.
* on __wakeup() exit.
* Possibly other similar checkpoints.


The key compromise, however, is that this still doesn't guarantee that 
there is no elephant in the house: there will be ways to create an 
object that don't go through the constructor, so won't trigger this 
check; and ways to manipulate an object that will put it into an invalid 
state. Not to mention that inside the constructor, $this will be usable 
as a normal object, unlike in a true 2-phase initialisation system like 
Swift's.


In short, we will still need runtime errors for attempting to read an 
uninitialized property, but they will be much less likely to happen 
accidentally and show up a long way from their cause.



I would be interested to hear if there are any use cases that this would 
break - a static factory method can defer as much initialisation as 
needed to the constructor, and cases where the constructor is bypassed 
will also bypass the check.


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Rasmus Schultz]

I apologize for the long posts, but Larry asked me to comment on this.

On Thu, Sep 20, 2018 at 5:52 PM Larry Garfield  wrote:

> I think the distinction here is that one group is arguing for "state of the
> data assertions" while the RFC as implemented is "setter assertion shorthand".

The point of the setter assertions is to provide guarantees about the state of
the data - there is literally no difference.

> That is, it doesn't assert that a value IS a given type, but that it can only
> be SET TO a given type.

That is literally the same thing - if it can only be set to a given
type, is can only
BE a given type.

The problem here is you want to make exemptions for null as type - as though
nulls aren't types (which they are) and as though nullable types aren't distinct
from the types they're derived from. (again, they are.)

> I don't think a complete IS enforcement is possible given PHP's nature.

I don't think that, and I don't expect that - I'm not suggesting we enforce
anything statically, I'm merely suggesting that a constructor needs to satisfy
the constraints specified by the class.

If you've type-hinted a property as int, you don't allow strings - that would be
pointless, right?

But that is precisely the problem we're talking about - if you've type-hinted a
property as non-nullable int, it shouldn't allow null... but that is
literally the
exemption you want to allow for - you just want to annotate the property
with an additional meta-data property "unintialized", which is literally the
same as adding a boolean "is set" for every property in your model.

> This isn't a compile time check
> either:
>
> $b = 'foo';
> test($b);
>
> It's a runtime TypeError, not compile time.

This actually illustrates my point nicely - the variable $b in this
case has nothing
to do with the state of the parameter var inside the function body,
until you pass
it via a function call. That's perfectly fine. You'll get an error at
the point where
the parameter type-constraint was violated - you can look at a stack-trace and
debug that easily.

Now take your example and call a constructor instead of a function:

class Test {
public string $b;
}

$b = 'foo';
$test = new Test();

Your constructor call generates no run-time error here, and the program
continues to execute with $test in a state that, according to specification of
the class itself, isn't valid.

Since the constructor is how a valid instance of Test gets generated in the
first place, you've missed your *only* chance to enforce those constraints -
meaning, you've missed the only opportunity you had to verify that the
constructor does in deed generate an instance of Test that lives up to
Test's own specification of what a Test instance is.

> To wit, could we add an engine check to scan an object and make sure its
> objects are all type valid right-now (viz, nothing is unitialized), and then
> call it on selected actions automatically and allow users to call it at
> arbitrary times if they are doing more esoteric things?

In my opinion, this is a solution to the problem we created when we decided
every property should internally be annotated with an "initialized" boolean
property - you have all this extra state that wasn't part of the specification
of the class itself, and now you have to deal with that state.

In my opinion, tracking this extra state *during the constructor call* is
acceptable and necessary in a scripting language like PHP - I never
asked for static type-checking, I'm merely asking for this check to be
built-into the language and performed at run-time when you exit the
constructor, e.g. at the last moment where you can feasibly perform
this check.

If you don't perform that check, you have no guarantees at all.

Consider this example:

function login(int $user_id) {
  // ...
}

Inside the body of this function, you can safely assume you have an integer,
right? A basic guarantee provided by the language.

Now consider this alternative:

function login(User $user) {
  // ...
}

Inside the body of this function, you'd assume you have a valid instance
of User, right? The same basic guarantee provided by the language.

Wrong. Something might be "unintialized". This might in fact not be a valid
instance of User, it might be only partially initialized.

This is a problem, because I want my type User to be a reliable type - as
reliable as any other type.

Integers for example is nice, because I know I'm going to be able to add,
subtract, multiple, divide, and so on - if you've type-hinted a parameter as
int, you know it has those abilities, you know the + operator isn't going to
fail because there's a special kind of int that doesn't work with the
+ operator.

We want those same guarantees from our own types, that's all.

In the case where a type *doesn't* provide such a guarantee, it can explicitly
state that something is nullable - not guaranteed to be set. You have that
option already, you don't need unintialized properties for that.

If there 

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Larry Garfield]

On Friday, September 21, 2018 10:25:50 AM CDT Rasmus Schultz wrote:
> On Fri, Sep 21, 2018 at 10:24 AM Lester Caine  wrote:
> > Ignoring the debate on uninitialized/null ... not all objects ARE
> > invariant
> 
> hence nullable types.
> 
> > and there are very good reasons for not setting values for
> > everything, but it seems that these types of object are deemed to be
> > 'bad coding' where in fact the simply have elements that yet to be
> > 'initialized' if at all for this instance of the object.
> 
> that's what nullable types are for.
> 
> > The constructor
> > simply creates those elements that need to exit and does nothing with
> > the holders for elements that have yet to be populated ... they stay null.
> 
> hence nullable types.
> 
> the point of using type-hints on the properties of a class is to describe
> the invariant state of that class - if the state of an instance of that
> class is not what the class itself prescribed/promised at the time when you
> return from the constructor, what's the point?
> 
> the only difference between using nullable vs non-nullable property
> type-hints then, is whether you can set them *back* to null after setting
> them to value - but it's okay for them to return from the constructor in
> a "null-like" state?
> 
> this doesn't provide *any* additional guarantees:
> 
> class Foo {
> public int $bar;
> }
> 
> $foo = new Foo(); // invalid state allowed
> 
> $foo->bar = 123; // valid state
> 
> $foo->bar = null; // invalid state NOT allowed?!
> 
> Have the effects on the null coalesce operator even been considered?
> 
> $bar = $foo->bar ?? "what";
> 
> Is unintialized "null-like enough" or will this trigger an error?
> 
> Extremely confusing.
> 
> Type-annotations are essentially assertions about the state of a program -
> if you can't count on those assertions to be fulfilled (which you
> can't if they're
> not checked at the time of initialization) then they're not useful.
> 
> The bottom line for me is that property type-hints were supposed to make
> my programs more predictable, make the language more reliable.
> 
> Instead, we've introduced a whole new kind of uncertainties, new ways to
> write unpredictable code, a new kind of null that makes the language even
> more unreliable.
> 
> In terms of reliability, it's actually sub-par to hand-written accessors.
> 
> Shorter syntax, reflection support, great - but ultimately at the cost of
> reliability and predictable state.
> 
> For one, what good is reflection, if it tells me I can expect a property to
> be an integer, and it turns out it doesn't have a value after all?
> 
> If you want horrible code with no guarantees, there are plenty of ways to
> do that already - you don't need property type-hints for anything more than
> mere convenience in the first place.

Rasmus, would the "checkpoint validity checks" I suggested in another branch 
of this thread ameliorate your concerns, at least to some degree?  I think 
they're as good as we'd be able to get, given the nature of PHP, but should at 
least cover the most common cases.

--Larry Garfield


signature.asc
Description: This is a digitally signed message part.

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Christoph M. Becker]

On 21.09.2018 at 17:25, Rasmus Schultz wrote:

> this doesn't provide *any* additional guarantees:
> 
> class Foo {
> public int $bar;
> }
> 
> $foo = new Foo(); // invalid state allowed
> 
> $foo->bar = 123; // valid state
> 
> $foo->bar = null; // invalid state NOT allowed?!
>
> [snip]
>
> In terms of reliability, it's actually sub-par to hand-written accessors.

You have no guarantee that a declared public property even exists
(regardless of the Typed Properties 2.0 RFC), because it might have been
unset.  And no, the property is not really NULL in this case, but rather
undefined.

-- 
Christoph M. Becker

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

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Rasmus Schultz]

On Fri, Sep 21, 2018 at 10:24 AM Lester Caine  wrote:

> Ignoring the debate on uninitialized/null ... not all objects ARE
> invariant

hence nullable types.

> and there are very good reasons for not setting values for
> everything, but it seems that these types of object are deemed to be
> 'bad coding' where in fact the simply have elements that yet to be
> 'initialized' if at all for this instance of the object.

that's what nullable types are for.

> The constructor
> simply creates those elements that need to exit and does nothing with
> the holders for elements that have yet to be populated ... they stay null.

hence nullable types.

the point of using type-hints on the properties of a class is to describe
the invariant state of that class - if the state of an instance of that class
is not what the class itself prescribed/promised at the time when you
return from the constructor, what's the point?

the only difference between using nullable vs non-nullable property
type-hints then, is whether you can set them *back* to null after setting
them to value - but it's okay for them to return from the constructor in
a "null-like" state?

this doesn't provide *any* additional guarantees:

class Foo {
public int $bar;
}

$foo = new Foo(); // invalid state allowed

$foo->bar = 123; // valid state

$foo->bar = null; // invalid state NOT allowed?!

Have the effects on the null coalesce operator even been considered?

$bar = $foo->bar ?? "what";

Is unintialized "null-like enough" or will this trigger an error?

Extremely confusing.

Type-annotations are essentially assertions about the state of a program -
if you can't count on those assertions to be fulfilled (which you
can't if they're
not checked at the time of initialization) then they're not useful.

The bottom line for me is that property type-hints were supposed to make
my programs more predictable, make the language more reliable.

Instead, we've introduced a whole new kind of uncertainties, new ways to
write unpredictable code, a new kind of null that makes the language even
more unreliable.

In terms of reliability, it's actually sub-par to hand-written accessors.

Shorter syntax, reflection support, great - but ultimately at the cost of
reliability and predictable state.

For one, what good is reflection, if it tells me I can expect a property to be
an integer, and it turns out it doesn't have a value after all?

If you want horrible code with no guarantees, there are plenty of ways to
do that already - you don't need property type-hints for anything more than
mere convenience in the first place.

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

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Rowan Collins]

On Fri, 21 Sep 2018 at 15:11, Larry Garfield  wrote:

> Perhaps another disconnect here is that, in practice, the consumer of an
> object property is, in my experience, almost always "me".  I almost never
> have
> public properties on my objects.  On the rare occasion I do, it's for a
> "struct object" I'm using internally as a more self-documenting and memory
> efficient alternative to a nested associative array.


My impression is that people will be encouraged by this feature to
implement more value objects with public properties, where they currently
have getters and setters doing nothing but type checks; and thus more code
will be exposed to uninitialized properties if there is a bug in a
constructor.

Indeed, it's arguable that if all properties were private, there would be
no need to enforce type hints all, since analysis of where they were set
would be trivial.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Larry Garfield]

On Friday, September 21, 2018 4:20:20 AM CDT Rowan Collins wrote:
> On Thu, 20 Sep 2018 at 16:52, Larry Garfield  wrote:
> > I think the distinction here is that one group is arguing for "state of
> > the
> > data assertions" while the RFC as implemented is "setter assertion
> > shorthand".
> > That is, it doesn't assert that a value IS a given type, but that it can
> > only
> > be SET TO a given type.
> > 
> > I don't think a complete IS enforcement is possible given PHP's nature.
> > ...
> > That hasn't brought about the end of the world, so I'm not super worried
> > about
> > imperfect property checks destroying everything.
> > 
> > That said, I totally appreciate the desire as a consumer of an object to
> > know
> > that it's read-type-safe.
> 
> This is a useful distinction, thank you for putting it so clearly.
> 
> Perhaps it depends whether you are looking at the feature as a library
> author, or a library consumer: as an author, you want to protect "your"
> objects from invalid *assignments*, inside and outside the library; as a
> consumer, you want assurance that you can *use* the object in a particular
> way. The current implementation provides a good tool for the author, but
> falls short for the consumer.

Perhaps another disconnect here is that, in practice, the consumer of an 
object property is, in my experience, almost always "me".  I almost never have 
public properties on my objects.  On the rare occasion I do, it's for a 
"struct object" I'm using internally as a more self-documenting and memory 
efficient alternative to a nested associative array.

In either case, if I fail to initialize a variable the only code that would be 
impacted is... my own, usually in the same class (or occasionally in a 
subclass).  Finding the bug then is pretty straightforward, and it's my own 
damned fault, but therefore easy to fix.

In my experience at least, most of the modern code I see in the wild is the 
same way.  That means the potential impact of stray undefined properties 
roaming around the code base is really small.  Even vaguely reasonably 
structured code already avoids this problem.  I can't think of anything I've 
written in the last few years that wouldn't work this way, even with a 
constructor-exit-validation check, without any modification at all.

Naturally if someone is using a lot of public properties in their code the 
potential for "undefined" bugs increases.  That seems rather uncommon in my 
world, though.

> > To wit, could we add an engine check to scan an object and make sure its
> > objects are all type valid right-now (viz, nothing is unitialized), and
> > then
> > call it on selected actions automatically and allow users to call it at
> > arbitrary times if they are doing more esoteric things?
> > 
> > I'm thinking:
> > 
> > * on __construct() exit.
> > * on __wakeup() exit.
> > * Possibly other similar checkpoints.
> > * When a user calls is_fully_initialized($obj); (or something)
> > 
> > is_fully_initialized() would return bool. The other checkpoints would
> > throw a
> > TypeError.
> > 
> > 
> > That would layer on top of the current RFC cleanly, would give us the
> > read-
> > assurance that we'd like in the 95% case
> 
> I think this is a really sensible approach: as you say, it may never be
> possible to assert the invariant in every case, so checking the most common
> scenarios may be the pragmatic thing to do.
> 
> Conveniently, treating it as an occasional assertion, rather than a strict
> invariant, means we can keep the unset() lazy-initialization hack; it's
> still an odd feature IMO, but probably not all that likely to be triggered
> by mistake.
> 
> Regards,

Another benefit, since it would, I think, boil down to a series of isset() 
calls implemented in C land the performance impact is probably not measurable.  
(Obviously we'd need to measure that... :-) )

--Larry Garfield

signature.asc
Description: This is a digitally signed message part.

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Rowan Collins]

On Thu, 20 Sep 2018 at 16:52, Larry Garfield  wrote:

> I think the distinction here is that one group is arguing for "state of
> the
> data assertions" while the RFC as implemented is "setter assertion
> shorthand".
> That is, it doesn't assert that a value IS a given type, but that it can
> only
> be SET TO a given type.
>
> I don't think a complete IS enforcement is possible given PHP's nature.
> ...
> That hasn't brought about the end of the world, so I'm not super worried
> about
> imperfect property checks destroying everything.
>
> That said, I totally appreciate the desire as a consumer of an object to
> know
> that it's read-type-safe.



This is a useful distinction, thank you for putting it so clearly.

Perhaps it depends whether you are looking at the feature as a library
author, or a library consumer: as an author, you want to protect "your"
objects from invalid *assignments*, inside and outside the library; as a
consumer, you want assurance that you can *use* the object in a particular
way. The current implementation provides a good tool for the author, but
falls short for the consumer.




> To wit, could we add an engine check to scan an object and make sure its
> objects are all type valid right-now (viz, nothing is unitialized), and
> then
> call it on selected actions automatically and allow users to call it at
> arbitrary times if they are doing more esoteric things?
>
> I'm thinking:
>
> * on __construct() exit.
> * on __wakeup() exit.
> * Possibly other similar checkpoints.
> * When a user calls is_fully_initialized($obj); (or something)
>
> is_fully_initialized() would return bool. The other checkpoints would
> throw a
> TypeError.
>

> That would layer on top of the current RFC cleanly, would give us the read-
> assurance that we'd like in the 95% case


I think this is a really sensible approach: as you say, it may never be
possible to assert the invariant in every case, so checking the most common
scenarios may be the pragmatic thing to do.

Conveniently, treating it as an occasional assertion, rather than a strict
invariant, means we can keep the unset() lazy-initialization hack; it's
still an odd feature IMO, but probably not all that likely to be triggered
by mistake.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Lester Caine]

On 21/09/2018 08:58, Rasmus Schultz wrote:

No matter how you twist it, uninitialized is the new null.

I'm fine with unintialized as an implementation detail that
ensures you can't read from properties while the constructor
is busy establishing the invariant.

I'm not at all fine with unintialized as a new language feature.


Ignoring the debate on uninitialized/null ... not all objects ARE 
invariant and there are very good reasons for not setting values for 
everything, but it seems that these types of object are deemed to be 
'bad coding' where in fact the simply have elements that yet to be 
'initialized' if at all for this instance of the object. The constructor 
simply creates those elements that need to exit and does nothing with 
the holders for elements that have yet to be populated ... they stay null.


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Rasmus Schultz]

On Thu, Sep 20, 2018 at 4:50 PM Levi Morrison  wrote:
>
> This will be my last reply to this thread. Fundamentally:
>
> class User {
>  public ?int $id;
>  public ?string $preferred_name;
>  public ?string $username;
>  }
>
> ^ This permits null properties at all times. This is acceptable
> behavior if null is valid for the domain. It is not valid for this
> domain -- all 3 are required.

If all three are required, your constructor needs to reflect that.

The reason constructors even exist in the first place is to initialize
the object's data members and establishing the invariant of the class.

Constructors are supposed to prepare objects for use.

Your (empty, implicit) constructor isn't doing that.

Your reasoning about this is circular - you want your properties to
be optionally initialized and non-null at the same time. You get
around this by coming up with a new term "undefined" for a
special kind of null that triggers run-time exceptions on read.

The whole idea is unnecessarily complex, and will certainly lead
to silent bugs that allow partially-initialized domain objects to
pass through many layers of a system without getting caught
until some code tries to read an "uninitialized" property.

function make_foo(): Foo {
   return new Foo(); // missing a property
}

function x() { ... }
function y() { ... }
function z() { ... }

x(y(z(make_foo()));

The instance travels through layers and layers of callls and
fails somewhere in the x() or y() function because of a missing
value ... why was the value missing? why wasn't it initialized?
where was it supposed to have been initialized? where did
this bad instance of Foo even come from?

All that information is lost in a call-stack that's long gone by
the time you invoke x() and you'll have to backtrack through
layers and layers of code to try to figure out where this bad
instance came from.

This will be an everyday thing with code like that.

To say that we don't need to enforce invariants at the time of
construction is to say we don't need to enforce them at all -
enforcing them "maybe later" is the same as not enforcing
them. That is, when they trigger an error, it's no different
from a null-value triggering a similar error.

No matter how you twist it, uninitialized is the new null.

I'm fine with unintialized as an implementation detail that
ensures you can't read from properties while the constructor
is busy establishing the invariant.

I'm not at all fine with unintialized as a new language feature.

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

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Larry Garfield]

On Thursday, September 20, 2018 6:50:45 AM CDT Rowan Collins wrote:
> On Thu, 20 Sep 2018 at 11:58, Nikita Popov  wrote:
> > I do not consider it advisable to require a null initialization as a
> > "first iteration" of the proposal. Regardless of what our intention might
> > be, the effect of such a restriction will not be "I'm not going to type
> > this property for now, because non-nullable types are not supported", it's
> > going to be "I'll give this a nullable type even though it isn't, because
> > that's better than no type at all." Use of nullable types where they are
> > not necessary would be a disastrous outcome of this proposal.
> 
> This, ultimately, is where we disagree. To me, the "non-nullable types"
> this proposal provides are non-nullable in name only, and using them does
> little more than adding a comment saying "I promise this won't be null".
> Encouraging people to use them gives them a false guarantee, and allowing
> them to do so prevents us adding a stricter version of the feature later.
> 
> > To move this discussion forward in a productive direction, we need a
> > concrete, detailed proposal of how enforcement of initialization should
> > work, while being compatible with secondary requirements.
> 
> It feels to me that many of the "secondary requirements" are actually
> separate problems which should be seen as pre-requisites, rather than
> constraints. The lazy initialization pattern seems to be a hack around lack
> of better support for property accessors. The mention of serializers
> needing custom methods of initialisation reminded me of the occasional
> discussion of better replacements for Serializable and JsonSerializable.
> And so on.
> 
> Fixing that list of pre-requisites would obviously take time, which is why
> I wanted to buy that time by releasing initialised-only type hints first,
> and working towards a greater goal.
> 
> However, I've probably beaten this drum long enough. I will hope to be
> wrong, and that making things stricter will still be possible later.
> 
> Regards,

If I may...

I think the distinction here is that one group is arguing for "state of the 
data assertions" while the RFC as implemented is "setter assertion shorthand".  
That is, it doesn't assert that a value IS a given type, but that it can only 
be SET TO a given type.

That naturally has some coverage holes.  The question then being "is that 
enough?"

I don't think a complete IS enforcement is possible given PHP's nature.  We 
don't enforce at compile time that you cannot call a function with an 
incorrect type; that's enforced at runtime, or by a static analyzer.  That is:

function test(int $a) {}

test($_GET['a']);

Cannot possibly be verified at compile time.  This isn't a compile time check 
either:

$b = 'foo';
test($b);

It's a runtime TypeError, not compile time.

That hasn't brought about the end of the world, so I'm not super worried about 
imperfect property checks destroying everything.

That said, I totally appreciate the desire as a consumer of an object to know 
that it's read-type-safe.  I also get that there's many different pathways by 
which an object could get initialized so there's no one clear validation 
chokepoint.

But... could we have multiple?

To wit, could we add an engine check to scan an object and make sure its 
objects are all type valid right-now (viz, nothing is unitialized), and then 
call it on selected actions automatically and allow users to call it at 
arbitrary times if they are doing more esoteric things?

I'm thinking:

* on __construct() exit.
* on __wakeup() exit.
* Possibly other similar checkpoints.
* When a user calls is_fully_initialized($obj); (or something)

is_fully_initialized() would return bool. The other checkpoints would throw a 
TypeError.

That would layer on top of the current RFC cleanly, would give us the read-
assurance that we'd like in the 95% case, wouldn't require any new syntax 
beyond a single function, and still lets serialization libraries do their 
thing.

If needed, perhaps there's a way we can let a serialization tool disable that 
check as an opt-out, and then the developer is just on-their-honor to get it 
right.  If it blows up later, well, file a bug with the serialization library.  
In a dynamic runtime language I don't think we'll ever be able to do better 
than that.

Would that be viable as a follow-up to the current RFC?

--Larry Garfield

signature.asc
Description: This is a digitally signed message part.

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Pedro Magalhães]

On Thu, Sep 20, 2018 at 12:50 PM Rowan Collins 
wrote:

> Encouraging people to use them gives them a false guarantee, and allowing
> them to do so prevents us adding a stricter version of the feature later.
>

What exactly would prevent us from enforcing it in the future? The way I
see it, whenever that would be possible, we could get rid of the
uninitialized state.

Regards,
Pedro

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Sara Golemon]

On Thu, Sep 20, 2018 at 9:50 AM, Levi Morrison  wrote:
> This will be my last reply to this thread.
>
This will be my first and, God willing, only reply to this thread.

> Fundamentally:
>
> class User {
>  public int $id;
>  public string $preferred_name;
>  public string $username;
>  }
>
> ^ This never permits null properties, and using them without
> initializing them is an error, and you get notified by the runtime
> that such a thing happened. This is good and desirable behavior.
>
This is bad and undesirable behavior.

Deferring the error to on-read makes the properties magic and
unknowable.  This is broken by design.  The RFC got my vote because
broken never stood in PHP's way, and at the very least, as a library
author, I am empowered to aggressively initialize my properties even
if the runtime gives me insufficient protections from coding errors.

A static analysis engine can pick up the slack where the engine falls
short, so that's my yes vote, but it's not an endorsement of the
fundamentally broken design.

-Sara

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

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Levi Morrison]

This will be my last reply to this thread. Fundamentally:

class User {
 public ?int $id;
 public ?string $preferred_name;
 public ?string $username;
 }

^ This permits null properties at all times. This is acceptable
behavior if null is valid for the domain. It is not valid for this
domain -- all 3 are required.

class User {
 public int $id;
 public string $preferred_name;
 public string $username;
 }

^ This never permits null properties, and using them without
initializing them is an error, and you get notified by the runtime
that such a thing happened. This is good and desirable behavior.

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

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Rasmus Schultz]

On Wed, Sep 19, 2018 at 10:04 PM Levi Morrison  wrote:

> I think this code should be allowed:
>
>class User {
> public int $id;
> public string $preferred_name;
> public string $username;
> }

This code is broken - by making the properties non-nullable, you're
literally saying "these properties will be initialized", then
proceeding to not initialize them. That's just incomplete code.

Note that we're talking about two different things here - I was
talking about bypassing declared constructors for technical reasons.

You're talking about omitting constructors from the declaration - but
all classes have a constructor. Not declaring it just implies an empty
constructor. You can even invoke it using reflection.

For your use-case, assuming you insist on writing bad code, is more
accurate like this:

class User {
 public ?int $id;
 public ?string $preferred_name;
 public ?string $username;
 }

These properties are valid without a constructor. You can safely infer
them as null, rather than as "uninitialized".

Non-nullable properties aren't valid without initialization. Not in
any language I've ever heard of.

Maybe PHP has to be the first to prove every other language right?

We have enough half-baked features and inconsistencies as it is.

We'll regret this forever. Like how Javascript developers regret
having null and undefined on a daily basis.

Uninitialized is the new null - it's the PHP equivalent of undefined
in Javascript.

Please no.

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

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Lester Caine]

On 19/09/2018 22:58, Marco Pivetta wrote:

Also, there are scenarios (discussed in typed properties v1) that make the
uninitialized state actually favorable (every serializer ever, like every
one, really).


I still find a problem with this idea that everything must be 
initialized. If I am working with business logic built into the database 
then 'NULL' is very much a valid state and when I create an object 
encapsulating a record it's values should be NULL until it is actually 
download, or more normally until a new record has SOME of it's fields 
populated. It is simply not sensible to be nailing down every variable 
that is being passed and it is certainly not 'bad coding' to be working 
with uninitialized data - it's handling just what needs to be 
initialized that is the job of the code. And that is unlikely to be done 
in the constructor!


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Rowan Collins]

On Thu, 20 Sep 2018 at 11:58, Nikita Popov  wrote:

> I do not consider it advisable to require a null initialization as a
> "first iteration" of the proposal. Regardless of what our intention might
> be, the effect of such a restriction will not be "I'm not going to type
> this property for now, because non-nullable types are not supported", it's
> going to be "I'll give this a nullable type even though it isn't, because
> that's better than no type at all." Use of nullable types where they are
> not necessary would be a disastrous outcome of this proposal.
>

This, ultimately, is where we disagree. To me, the "non-nullable types"
this proposal provides are non-nullable in name only, and using them does
little more than adding a comment saying "I promise this won't be null".
Encouraging people to use them gives them a false guarantee, and allowing
them to do so prevents us adding a stricter version of the feature later.



> To move this discussion forward in a productive direction, we need a
> concrete, detailed proposal of how enforcement of initialization should
> work, while being compatible with secondary requirements.
>

It feels to me that many of the "secondary requirements" are actually
separate problems which should be seen as pre-requisites, rather than
constraints. The lazy initialization pattern seems to be a hack around lack
of better support for property accessors. The mention of serializers
needing custom methods of initialisation reminded me of the occasional
discussion of better replacements for Serializable and JsonSerializable.
And so on.

Fixing that list of pre-requisites would obviously take time, which is why
I wanted to buy that time by releasing initialised-only type hints first,
and working towards a greater goal.

However, I've probably beaten this drum long enough. I will hope to be
wrong, and that making things stricter will still be possible later.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Nikita Popov]

On Wed, Sep 19, 2018 at 2:38 PM Rowan Collins 
wrote:

> On Tue, 11 Sep 2018 at 08:05, Bob Weinand  wrote:
>
> > Hey,
> >
> > As announced, we are starting the vote on typed properties today.
> >
> > The voting period is two weeks, until sometime in the evening on Tuesday
> > 25-09-2018.
> >
> > Please find the RFC at https://wiki.php.net/rfc/typed_properties_v2.
> >
>
>
> For the record, I still think we will come to regret allowing non-nullable
> type hints without any constraint on the author of the class to initialise
> them correctly. As proposed, the invalid state may only be detected when it
> causes a runtime error in completely unrelated code.
>
> I gather that the authors of C# are currently going through a painful
> development phase to introduce better support for non-nullable types, and
> having to include many compromises and handle many edge-cases because it
> was not done earlier. I realise this case is not completely comparable, but
> we have an opportunity to get this right first time, and not just take the
> easy option.
>
> I am therefore going to make one last plea: if we don't yet know how to
> assert that complex types are initialised, do not allow them to be
> non-nullable in the first version of this feature.
>
> That is, allow `class Foo { public ?Foo $foo = null; }`, but not `class Foo
> { public Foo $foo; }`.
>
> This would still be a huge improvement to the language, but leaves us free
> to design additional features to prevent Unitialized Property Errors
> becoming as hated as Null Pointer Exceptions in Java or C#.


I am sympathetic to the wish of reporting initialization errors during
construction rather than at the use-site. However, there is no clear
proposal on how this will be reconciled with other requirements that we
have, such as support of uninitialized properties for lazy initialization,
etc.

I do not consider it advisable to require a null initialization as a "first
iteration" of the proposal. Regardless of what our intention might be, the
effect of such a restriction will not be "I'm not going to type this
property for now, because non-nullable types are not supported", it's going
to be "I'll give this a nullable type even though it isn't, because that's
better than no type at all." Use of nullable types where they are not
necessary would be a disastrous outcome of this proposal.

To move this discussion forward in a productive direction, we need a
concrete, detailed proposal of how enforcement of initialization should
work, while being compatible with secondary requirements. I believe it goes
without saying that we cannot change the typed properties RFC in such a
substantive way at this point in time. However, if you or someone else can
bring forward an RFC that specifies the precise semantics of initialization
checks as you envision them and which is endorsed by maintainers of
libraries with special initialization requirements, then we still have a
lot of time to discuss and incorporate such a proposal before typed
properties ship in PHP 7.4.

Thanks,
Nikita

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Christian Stoller]

> -Ursprüngliche Nachricht-
> Von: Rowan Collins
> Gesendet: Mittwoch, 19. September 2018 23:47
> An: PHP Internals List
> Betreff: Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2
>
> On 19/09/2018 22:30, Marco Pivetta wrote:
> >
> > At least the approach without nullable properties will lead to a
> > Throwable when a read is attempted on an uninitialized object, which
> > is still better than nullability checks all over the place.
>
>
> Is it? Doesn't it just mean writing this:
>
> try {
> someFunction($object->propertyThatClaimsToBeNonNullable);
> } catch ( TypeError $e ) {
> ...
> }
>
> Instead of this:
>
> if ( ! is_null($object->propertyThatClaimsToBeNonNullable) ) {
> someFunction($object->propertyThatClaimsToBeNonNullable);
> } else {
> ...
> }
>
> For that matter, all I need to do is define someFunction as taking a
> non-nullable parameter, and I get the TypeError either way.
>
> Surely the point of a non-nullable property shouldn't be "it gives a
> slightly different error if it's not set", it should be "you don't have
> to worry about this not being set, because the language will enforce
> that somewhere". (And to cover your last point, that somewhere doesn't
> need to be the constructor, if requiring that is really such a big problem.)
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>

Just an idea: If an object is initialized without having all non-nullable 
properties initialized, one could store the instantiation place, and give this 
hint if an uninitialized property is accessed later.

Example:

// User.php

class User {
public Group $group;
}

// functions.php

function initUser() {
$user = new User(); // store this line and filename internally, because 
User::$group is uninitialized
return $user;
}

// index.php

$user = initUser();
echo $user->group->name; // Throws TypeError informing about access on 
uninitialized property and that it was initialized in file functions.php at 
line 3.


The TypeError still occurs but it makes it easy to find and fix the issue. And 
the same could be done with unsetting - save the place where an non-nullable 
property has been unsetted and inform the user where it happened if the 
unsetted property is accessed.

Best regards

Mit freundlichen Grüßen aus Paderborn

Christian Stoller
Web-Entwicklung

LEONEX Internet GmbH
Technologiepark 6
33100 Paderborn
Tel: +49 (5251) 4142-526
Fax: +49 (5251) 4142-501


HRB 8694 AG Paderborn
Geschäftsführer: Stephan Winter


LEONEX ist umgezogen: Bitte beachten Sie unsere neue Adresse sowie unsere neuen 
Rufnummern.
Wann dürfen wir Sie in unsere neuen Räumlichkeiten einladen?

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Marco Pivetta]

On Wed, Sep 19, 2018 at 11:46 PM Rowan Collins 
wrote:

> On 19/09/2018 22:30, Marco Pivetta wrote:
> >
> > At least the approach without nullable properties will lead to a
> > Throwable when a read is attempted on an uninitialized object, which
> > is still better than nullability checks all over the place.
>
>
> Is it? Doesn't it just mean writing this:
>
> try {
>  someFunction($object->propertyThatClaimsToBeNonNullable);
> } catch ( TypeError $e ) {
>  ...
> }
>
> Instead of this:
>
> if ( ! is_null($object->propertyThatClaimsToBeNonNullable) ) {
>  someFunction($object->propertyThatClaimsToBeNonNullable);
> } else {
>  ...
> }
>
> For that matter, all I need to do is define someFunction as taking a
> non-nullable parameter, and I get the TypeError either way.
>
> Surely the point of a non-nullable property shouldn't be "it gives a
> slightly different error if it's not set", it should be "you don't have
> to worry about this not being set, because the language will enforce
> that somewhere". (And to cover your last point, that somewhere doesn't
> need to be the constructor, if requiring that is really such a big
> problem.)
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>

That's what static analysis is for (see a bit above).

Sadly, static analysis doesn't really fit the engine out of the box, as PHP
is a bit too dynamic for that, and it doesn't really consider cross-file
declared symbols anyway.
Still, tools like PHPStan or Psalm can easily aid with that.

Also, there are scenarios (discussed in typed properties v1) that make the
uninitialized state actually favorable (every serializer ever, like every
one, really).

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Rowan Collins]

On 19/09/2018 22:30, Marco Pivetta wrote:


At least the approach without nullable properties will lead to a 
Throwable when a read is attempted on an uninitialized object, which 
is still better than nullability checks all over the place.



Is it? Doesn't it just mean writing this:

try {
    someFunction($object->propertyThatClaimsToBeNonNullable);
} catch ( TypeError $e ) {
    ...
}

Instead of this:

if ( ! is_null($object->propertyThatClaimsToBeNonNullable) ) {
    someFunction($object->propertyThatClaimsToBeNonNullable);
} else {
    ...
}

For that matter, all I need to do is define someFunction as taking a 
non-nullable parameter, and I get the TypeError either way.


Surely the point of a non-nullable property shouldn't be "it gives a 
slightly different error if it's not set", it should be "you don't have 
to worry about this not being set, because the language will enforce 
that somewhere". (And to cover your last point, that somewhere doesn't 
need to be the constructor, if requiring that is really such a big problem.)


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Marco Pivetta]

On Wed, Sep 19, 2018 at 11:17 PM Rowan Collins 
wrote:

> On 19/09/2018 21:04, Levi Morrison wrote:
> > I think this code should be allowed:
> >
> > class User {
> >  public int $id;
> >  public string $preferred_name;
> >  public string $username;
> >  }
>
> Why? What contract is being enforced by that class that is not enforced
> by this class?
>
> class User {
>  public ?int $id=null;
>  public ?string $preferred_name=null;
>  public ?string $username=null;
>  }
>
> Both require the consumer of the class to trust that someone, somewhere,
> has initialised the fields (and not subsequently unset them).
>
> Or have I misunderstood what you intended with that example?
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>

At least the approach without nullable properties will lead to a Throwable
when a read is attempted on an uninitialized object, which is still better
than nullability checks all over the place.

And yes, constructing an object without going through its constructor is
quite common anyway - this was indeed part of the upfront discussion, and
is also part of why I gave a +1 to the current RFC.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Rowan Collins]

On 19/09/2018 21:04, Levi Morrison wrote:

I think this code should be allowed:

class User {
 public int $id;
 public string $preferred_name;
 public string $username;
 }


Why? What contract is being enforced by that class that is not enforced 
by this class?


   class User {
public ?int $id=null;
public ?string $preferred_name=null;
public ?string $username=null;
}

Both require the consumer of the class to trust that someone, somewhere, has 
initialised the fields (and not subsequently unset them).

Or have I misunderstood what you intended with that example?

Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Levi Morrison]

On Wed, Sep 19, 2018 at 1:06 PM Rasmus Schultz  wrote:
>
> On Wed, Sep 19, 2018 at 7:43 PM Rowan Collins  wrote:
>
> > I agree that this is a hard problem, but I don't agree that this decision
> > is being made "for now". If we allow "non-nullable but uninitialized"
> > properties now, it will be extremely hard to change their behaviour in
> > future.
>
> I'm with Rowan on this one.
>
> This concept of "uninitialized" frankly seems like an allowance for
> people who insist on writing poor code.
>
> Nulls are bad, and "unintialized" is just another kind of "null" with
> a built-in run-time type-check that executes on read - too late.
>
> The first example given is just bad:
>
> class Point {
> public float $x, $y;
>
> private function __construct() {}
>
> public static function fromEuclidean(float $x, float $y) {
> $point = new Point;
> $point->x = $x;
> $point->y = $y;
> return $point;
> }
> }
>
> You define two invariants: $x and $y must be floats - and then proceed
> to break those constraints in the constructor?
>
> Wrong. The RFC itself accurately states that "this code can be
> rewritten to indirect through __construct() instead" - as shown in the
> previous example.
>
> Now why would you deliberately open the fences and knowingly invite
> people to write poor code like this?
>
> As for the second example:
>
> class Point {
> public float $x, $y;
>
> public function __construct(float $x, float $y) {
> $this->doSomething();
> $this->x = $x;
> $this->y = $y;
> }
> }
>
> If doSomething() attempts to read an uninitialized property while the
> constructor is still executing, throwing a helpful "uninitialized"
> error is fine.
>
> But, in my opinion, once the constructor has executed, the invariants
> as declared by the class itself must be satisfied.
>
> If there's one meaningful use-case for allowing objects in a
> partially-initialized state, it's during
> hydration/unserialization/reflection scenarios, maybe - but in those
> cases, you're willfully bypassing the constructor; it's not the
> everyday 95% use-case and some risk is acceptable here, you'll get
> around it with tests. But nobody wants to write tests all day to see
> if any classes contain "unininitialized" properties - that misses half
> the whole point of being able to declare those types in the first
> place, e.g. makes type-hinted private/protected properties totally
> unreliable.
>
> Once this is in a release, it'll be unfixable, and in my opinion will
> likely go down in history as another one of those little things we
> wish we could go back in time and fix :-/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

PHP permits skipping constructors. The code may not work if you do so,
but it's the state of how things are. Validating after a constructor
call will not catch all issues while requiring a constructor, whereas
I think this code should be allowed:

   class User {
public int $id;
public string $preferred_name;
public string $username;
}

I doubt we will come to a resolution -- these points were already
pointed out in the discussion phase.

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

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Rasmus Schultz]

On Wed, Sep 19, 2018 at 7:43 PM Rowan Collins  wrote:

> I agree that this is a hard problem, but I don't agree that this decision
> is being made "for now". If we allow "non-nullable but uninitialized"
> properties now, it will be extremely hard to change their behaviour in
> future.

I'm with Rowan on this one.

This concept of "uninitialized" frankly seems like an allowance for
people who insist on writing poor code.

Nulls are bad, and "unintialized" is just another kind of "null" with
a built-in run-time type-check that executes on read - too late.

The first example given is just bad:

class Point {
public float $x, $y;

private function __construct() {}

public static function fromEuclidean(float $x, float $y) {
$point = new Point;
$point->x = $x;
$point->y = $y;
return $point;
}
}

You define two invariants: $x and $y must be floats - and then proceed
to break those constraints in the constructor?

Wrong. The RFC itself accurately states that "this code can be
rewritten to indirect through __construct() instead" - as shown in the
previous example.

Now why would you deliberately open the fences and knowingly invite
people to write poor code like this?

As for the second example:

class Point {
public float $x, $y;

public function __construct(float $x, float $y) {
$this->doSomething();
$this->x = $x;
$this->y = $y;
}
}

If doSomething() attempts to read an uninitialized property while the
constructor is still executing, throwing a helpful "uninitialized"
error is fine.

But, in my opinion, once the constructor has executed, the invariants
as declared by the class itself must be satisfied.

If there's one meaningful use-case for allowing objects in a
partially-initialized state, it's during
hydration/unserialization/reflection scenarios, maybe - but in those
cases, you're willfully bypassing the constructor; it's not the
everyday 95% use-case and some risk is acceptable here, you'll get
around it with tests. But nobody wants to write tests all day to see
if any classes contain "unininitialized" properties - that misses half
the whole point of being able to declare those types in the first
place, e.g. makes type-hinted private/protected properties totally
unreliable.

Once this is in a release, it'll be unfixable, and in my opinion will
likely go down in history as another one of those little things we
wish we could go back in time and fix :-/

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

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Rowan Collins]

On Wed, 19 Sep 2018 at 16:57, Levi Morrison  wrote:

> I posit that this code:
>
> class Foo {
> public Foo $foo;
> }
>
> Is superior to this code:
>
> class Foo {
> public ?Foo $foo = null;
> }
>
> If after "initialization" that `$foo` is guaranteed to always contain
> an object of type `Foo`.



Yes, IF it guaranteed; but the current proposal offers no such guarantee.
Whichever of those definitions is used, the following code may fail:

function expectsFoo(Foo $foo) {
assert($foo->foo instanceOf Foo);
}



> The reason is simple: for the actual lifetime
> of the object the former correctly states that it will never be null,
> while the latter opens up possibilities of it.


It correctly states that it will never be null, but it incorrectly implies
that it will always be an instance of Foo.

It's not even true that *once initialised* the property will always contain
a Foo, because (if I understand it correctly) it is also allowed to call
unset() on a non-nullable property at any time.



> That is, the former
> provides *better* support for non-nullable types.
>

The property is only "non-nullable" because we have invented a new state,
very similar to null, and called it something other than "null".



> To prevent all forms of initialization errors we would have to do
> analysis at the initialization site and prevent dynamic behaviors in
> that region. For now I believe such things are better left to static
> analysis tools than the engine.
>

I agree that this is a hard problem, but I don't agree that this decision
is being made "for now". If we allow "non-nullable but uninitialized"
properties now, it will be extremely hard to change their behaviour in
future.

My request is emphatically not to reject the entire RFC until this is
solved. It is to say that "for now", all typed properties must be
initialised inline to a valid value; and by implication, that a
non-nullable object hint cannot be used.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Levi Morrison]

On Wed, Sep 19, 2018 at 6:38 AM Rowan Collins  wrote:
>
> On Tue, 11 Sep 2018 at 08:05, Bob Weinand  wrote:
>
> > Hey,
> >
> > As announced, we are starting the vote on typed properties today.
> >
> > The voting period is two weeks, until sometime in the evening on Tuesday
> > 25-09-2018.
> >
> > Please find the RFC at https://wiki.php.net/rfc/typed_properties_v2.
> >
>
>
> For the record, I still think we will come to regret allowing non-nullable
> type hints without any constraint on the author of the class to initialise
> them correctly. As proposed, the invalid state may only be detected when it
> causes a runtime error in completely unrelated code.
>
> I gather that the authors of C# are currently going through a painful
> development phase to introduce better support for non-nullable types, and
> having to include many compromises and handle many edge-cases because it
> was not done earlier. I realise this case is not completely comparable, but
> we have an opportunity to get this right first time, and not just take the
> easy option.
>
> I am therefore going to make one last plea: if we don't yet know how to
> assert that complex types are initialised, do not allow them to be
> non-nullable in the first version of this feature.
>
> That is, allow `class Foo { public ?Foo $foo = null; }`, but not `class Foo
> { public Foo $foo; }`.
>
> This would still be a huge improvement to the language, but leaves us free
> to design additional features to prevent Unitialized Property Errors
> becoming as hated as Null Pointer Exceptions in Java or C#.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]

I posit that this code:

class Foo {
public Foo $foo;
}

Is superior to this code:

class Foo {
public ?Foo $foo = null;
}

If after "initialization" that `$foo` is guaranteed to always contain
an object of type `Foo`. The reason is simple: for the actual lifetime
of the object the former correctly states that it will never be null,
while the latter opens up possibilities of it. That is, the former
provides *better* support for non-nullable types.

To prevent all forms of initialization errors we would have to do
analysis at the initialization site and prevent dynamic behaviors in
that region. For now I believe such things are better left to static
analysis tools than the engine.

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

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

[Rowan Collins]

On Tue, 11 Sep 2018 at 08:05, Bob Weinand  wrote:

> Hey,
>
> As announced, we are starting the vote on typed properties today.
>
> The voting period is two weeks, until sometime in the evening on Tuesday
> 25-09-2018.
>
> Please find the RFC at https://wiki.php.net/rfc/typed_properties_v2.
>


For the record, I still think we will come to regret allowing non-nullable
type hints without any constraint on the author of the class to initialise
them correctly. As proposed, the invalid state may only be detected when it
causes a runtime error in completely unrelated code.

I gather that the authors of C# are currently going through a painful
development phase to introduce better support for non-nullable types, and
having to include many compromises and handle many edge-cases because it
was not done earlier. I realise this case is not completely comparable, but
we have an opportunity to get this right first time, and not just take the
easy option.

I am therefore going to make one last plea: if we don't yet know how to
assert that complex types are initialised, do not allow them to be
non-nullable in the first version of this feature.

That is, allow `class Foo { public ?Foo $foo = null; }`, but not `class Foo
{ public Foo $foo; }`.

This would still be a huge improvement to the language, but leaves us free
to design additional features to prevent Unitialized Property Errors
becoming as hated as Null Pointer Exceptions in Java or C#.

Regards,
-- 
Rowan Collins
[IMSoP]

[PHP-DEV] [RFC] [VOTE] Typed properties v2

[Bob Weinand]

Hey,

As announced, we are starting the vote on typed properties today.

The voting period is two weeks, until sometime in the evening on Tuesday 
25-09-2018.

Please find the RFC at https://wiki.php.net/rfc/typed_properties_v2.

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Rowan Collins]

On 20/11/2016 16:24, Rasmus Schultz wrote:
A consistent, complete type-system is not a "trend". 

[...]

Anyways, glad to hear Bob Weinland has been working on typed references and
the RFC is not dead :-)


Just to reiterate, I don't agree that these two sentiments go together: 
a consistent type system requires a lot more than adding type keywords 
in a few more bits of syntax, then coming up with a meaning for that syntax.


The conversation we need to have is not "how should typed properties 
work", but "what kind of type constraints do we want, and where should 
they be checked".


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Rasmus Schultz]

> if you've hired developers that care more about trends than your
application then you've hired the wrong developers.

A consistent, complete type-system is not a "trend".

In my experience, good developers notice things like inconsistency - and
they generally do not like it.

I am personally *not* about trends, and don't tend to count developers who
buy into hype as "good" developers - those would *not* be the developers
I'd be concerned about walking. We can hire developers like those again
easily.

> If every language is the same then what's the point of different
languages?

I'm not arguing "PHP should be more like X", I'm arguing for consistency
and completeness - an irrational fear of having certain similarities with
other languages really does not work as an argument against that.

Anyways, glad to hear Bob Weinland has been working on typed references and
the RFC is not dead :-)


On Sat, Nov 19, 2016 at 3:49 PM, Daniel Morris 
wrote:

> If every language is the same then what's the point of different
> languages? People use Scala and PHP for different things, if your
> developers are considering walking for that reason then they should
> evaluate whether they want to build things or whether they want to be
> trendy. Good (heck, great) developers will put to best use the tools
> they have available. Migrate to Go, and watch every one of them
> eventually complain about how they're having to check for err against
> every function call since functions return multiple values, have them
> migrate to Scala and watch their frustration as the time to change
> visibility is dropped significantly; if you've hired developers that
> care more about trends than your application then you've hired the wrong
> developers.
>
> --
> Daniel Morris
> dan...@honestempire.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Rowan Collins]

On 19/11/2016 14:04, Rasmus Schultz wrote:

lack of features
and consistency [...] where these features were engineered
into the language from the design stage, rather than being added on a bit
at a time.


I think the consistency and "engineered in" parts of this are more 
important than people give them credit for. Adding type hints to a 
dynamic language is not a trivial thing; what do those type hints 
actually *mean*?



He actually had something like "public int $id" in a class-declaration on
his screen, and was genuinely confused - he simply assumed that would work


What did he expect that declaration to do? Did he expect his program not 
to compile if he wrote some code that assigned a string? Did he expect 
to have to run a static analysis tool to detect errors? Did he expect 
the run-time to insert an assertion on every assignment and raise a 
runtime error? Did he expect this to happen even in production, or only 
in a development-only "checked" mode? All of these are possible 
behaviours, implemented in other languages.


I've written some of my thoughts on how it *could* work in this blog 
post: http://rwec.co.uk/q/php-type-system


Before we add type hints anywhere else in the language, I think we need 
to think about what we are actually working towards. Otherwise, we're 
going to end up with a mess of inconsistent rules because each set of 
type hints was added separately with slightly different semantics and 
caveats.


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Stephen Reay]

Thanks for your work on this Bob, it is *very* appreciated!

> On 19 Nov 2016, at 21:51, Bob Weinand  wrote:
> 
> Hey there,
> 
> I’ve actually been working on an implementation covering also typed 
> references, so that it’s possible to create references to a typed property, 
> which had been a major concern back then.
> 
> See also: 
> https://github.com/bwoebi/php-src/compare/typed_properties...bwoebi:typed_ref_properties
> 
> I’m planning to revive the RFC soon.
> 
> Bob
> 
>> Am 19.11.2016 um 15:04 schrieb Rasmus Schultz :
>> 
>> Heh, so, this week, a coworker of mine started using PHP 7, and he calls me
>> over, and he's like, "I don't get it, I had heard PHP 7 was supposed to
>> have type-hints now - it worked for return-types, but what am I doing
>> wrong, I can't seem to get this to work for properties?"
>> 
>> He actually had something like "public int $id" in a class-declaration on
>> his screen, and was genuinely confused - he simply assumed that would work,
>> since it worked for return-types. When I explained to him that, no, PHP 7
>> still isn't type-hinted, it's *more* type-hinted, but still not fully
>> type-hinted, he gave me the lemon-face. You know the one. Like you just ate
>> a lemon. Yeah.
>> 
>> I don't think there's a developer on my team and this point who isn't at
>> least checking out other languages in frustration with the lack of features
>> and consistency. I'm starting to feel like we're at risk of some of our
>> best, young developers walking, if somebody offers them a chance to work
>> with more "exciting" languages like Scala, Go, Dart, etc. - I'm not trying
>> to say that proper type-hinting is the whole answer, but I believe it would
>> go a long way towards consistency and the sense of completeness you get
>> from some of the competing languages, where these features were engineered
>> into the language from the design stage, rather than being added on a bit
>> at a time.
>> 
>> Any plans to revive this RFC or is it officially dead?
>> 
>> 
>> On Thu, Jun 23, 2016 at 11:08 PM, Pascal MARTIN, AFUP <
>> mail...@pascal-martin.fr> wrote:
>> 
>>> Le 10/06/2016 12:38, Joe Watkins a écrit :
>>> 
The vote for typed properties has been restarted.
 
>>> 
>>> Hi,
>>> 
>>> We, at AFUP, often tend to be on the "more static / strict types" side of
>>> things, and it remains this way for this RFC -- which means we would be +1
>>> for typed properties.
>>> 
>>> A few noted this was not quite "the PHP way", while the majority felt this
>>> was in line with previous changes (like scalar type declarations, nullable
>>> types...) and could prove interesting for complex applications.
>>> 
>>> Judging from where the votes are right now, I'm guessing this RFC will not
>>> pass, but, in any case, thanks for your work on this!
>>> 
>>> There are more "yes" than "no", so maybe it will open a path towards
>>> something, maybe a bit different, in another future version...
>>> 
>>> --
>>> Pascal MARTIN, AFUP - French UG
>>> http://php-internals.afup.org/
> 
> --
> 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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Bob Weinand]

Hey there,

I’ve actually been working on an implementation covering also typed references, 
so that it’s possible to create references to a typed property, which had been 
a major concern back then.

See also: 
https://github.com/bwoebi/php-src/compare/typed_properties...bwoebi:typed_ref_properties

I’m planning to revive the RFC soon.

Bob

> Am 19.11.2016 um 15:04 schrieb Rasmus Schultz :
> 
> Heh, so, this week, a coworker of mine started using PHP 7, and he calls me
> over, and he's like, "I don't get it, I had heard PHP 7 was supposed to
> have type-hints now - it worked for return-types, but what am I doing
> wrong, I can't seem to get this to work for properties?"
> 
> He actually had something like "public int $id" in a class-declaration on
> his screen, and was genuinely confused - he simply assumed that would work,
> since it worked for return-types. When I explained to him that, no, PHP 7
> still isn't type-hinted, it's *more* type-hinted, but still not fully
> type-hinted, he gave me the lemon-face. You know the one. Like you just ate
> a lemon. Yeah.
> 
> I don't think there's a developer on my team and this point who isn't at
> least checking out other languages in frustration with the lack of features
> and consistency. I'm starting to feel like we're at risk of some of our
> best, young developers walking, if somebody offers them a chance to work
> with more "exciting" languages like Scala, Go, Dart, etc. - I'm not trying
> to say that proper type-hinting is the whole answer, but I believe it would
> go a long way towards consistency and the sense of completeness you get
> from some of the competing languages, where these features were engineered
> into the language from the design stage, rather than being added on a bit
> at a time.
> 
> Any plans to revive this RFC or is it officially dead?
> 
> 
> On Thu, Jun 23, 2016 at 11:08 PM, Pascal MARTIN, AFUP <
> mail...@pascal-martin.fr> wrote:
> 
>> Le 10/06/2016 12:38, Joe Watkins a écrit :
>> 
>>> The vote for typed properties has been restarted.
>>> 
>> 
>> Hi,
>> 
>> We, at AFUP, often tend to be on the "more static / strict types" side of
>> things, and it remains this way for this RFC -- which means we would be +1
>> for typed properties.
>> 
>> A few noted this was not quite "the PHP way", while the majority felt this
>> was in line with previous changes (like scalar type declarations, nullable
>> types...) and could prove interesting for complex applications.
>> 
>> Judging from where the votes are right now, I'm guessing this RFC will not
>> pass, but, in any case, thanks for your work on this!
>> 
>> There are more "yes" than "no", so maybe it will open a path towards
>> something, maybe a bit different, in another future version...
>> 
>> --
>> Pascal MARTIN, AFUP - French UG
>> http://php-internals.afup.org/

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Daniel Morris]

If every language is the same then what's the point of different
languages? People use Scala and PHP for different things, if your
developers are considering walking for that reason then they should
evaluate whether they want to build things or whether they want to be
trendy. Good (heck, great) developers will put to best use the tools
they have available. Migrate to Go, and watch every one of them
eventually complain about how they're having to check for err against
every function call since functions return multiple values, have them
migrate to Scala and watch their frustration as the time to change
visibility is dropped significantly; if you've hired developers that
care more about trends than your application then you've hired the wrong
developers.

--
Daniel Morris
dan...@honestempire.com

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Rasmus Schultz]

Heh, so, this week, a coworker of mine started using PHP 7, and he calls me
over, and he's like, "I don't get it, I had heard PHP 7 was supposed to
have type-hints now - it worked for return-types, but what am I doing
wrong, I can't seem to get this to work for properties?"

He actually had something like "public int $id" in a class-declaration on
his screen, and was genuinely confused - he simply assumed that would work,
since it worked for return-types. When I explained to him that, no, PHP 7
still isn't type-hinted, it's *more* type-hinted, but still not fully
type-hinted, he gave me the lemon-face. You know the one. Like you just ate
a lemon. Yeah.

I don't think there's a developer on my team and this point who isn't at
least checking out other languages in frustration with the lack of features
and consistency. I'm starting to feel like we're at risk of some of our
best, young developers walking, if somebody offers them a chance to work
with more "exciting" languages like Scala, Go, Dart, etc. - I'm not trying
to say that proper type-hinting is the whole answer, but I believe it would
go a long way towards consistency and the sense of completeness you get
from some of the competing languages, where these features were engineered
into the language from the design stage, rather than being added on a bit
at a time.

Any plans to revive this RFC or is it officially dead?


On Thu, Jun 23, 2016 at 11:08 PM, Pascal MARTIN, AFUP <
mail...@pascal-martin.fr> wrote:

> Le 10/06/2016 12:38, Joe Watkins a écrit :
>
>>  The vote for typed properties has been restarted.
>>
>
> Hi,
>
> We, at AFUP, often tend to be on the "more static / strict types" side of
> things, and it remains this way for this RFC -- which means we would be +1
> for typed properties.
>
> A few noted this was not quite "the PHP way", while the majority felt this
> was in line with previous changes (like scalar type declarations, nullable
> types...) and could prove interesting for complex applications.
>
> Judging from where the votes are right now, I'm guessing this RFC will not
> pass, but, in any case, thanks for your work on this!
>
> There are more "yes" than "no", so maybe it will open a path towards
> something, maybe a bit different, in another future version...
>
> --
> Pascal MARTIN, AFUP - French UG
> http://php-internals.afup.org/
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Pascal MARTIN, AFUP]

Le 10/06/2016 12:38, Joe Watkins a écrit :

 The vote for typed properties has been restarted.


Hi,

We, at AFUP, often tend to be on the "more static / strict types" side 
of things, and it remains this way for this RFC -- which means we would 
be +1 for typed properties.


A few noted this was not quite "the PHP way", while the majority felt 
this was in line with previous changes (like scalar type declarations, 
nullable types...) and could prove interesting for complex applications.


Judging from where the votes are right now, I'm guessing this RFC will 
not pass, but, in any case, thanks for your work on this!


There are more "yes" than "no", so maybe it will open a path towards 
something, maybe a bit different, in another future version...


--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Lester Caine]

On 22/06/16 22:21, Rowan Collins wrote:
> But we haven't ever decided what that road is, so how can we know what
> the next step is? What if we realise that the way we've implemented
> typed properties is completely at odds with the way we want to implement
> typed locals?

Why should a 'var' inside a class be any different to a 'var' in an
array or a simple static 'var'. If we add a set of constraints to the
basic 'var' all of those constraints should be consistent where ever it
is used, but currently there is no consistent way to add a constraint to
the basic 'var'.

Now if there is some fundamental reason not to allow those constraints,
then that block should also apply consistently. The historic var is a
totally flexible container with no constraints, and all of the actions
to block NULL or 'string integers' and the like should work exactly the
same everywhere, not requiring different methods un-associated with
defining the var.

But I still can't see why NOT having to worry about typing makes
learning PHP more difficult. I still have no idea why I would use
'Reflections' and have no references to it in my own code and in my book
that makes no difference to making code work. Typing is only a subset of
data validation, and so I would teach that and not worry about any of
the current 'type' functions as they get in the way.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Rowan Collins]

On 22/06/2016 20:06, Rasmus Schultz wrote:

With Dart, you have a choice - you can actually toggle whether or no
type-checks should be performed at run-time. It's probably the best of
those two references, if you're looking for inspiration for PHP.


Ooh, that sounds interesting, I'll have to read up on it. :)



In PHP, every type-check is performed at run-time, and type-hints are
reflected - that's extremely important, and something Hack got
horribly wrong, as the type-hints they introduced are merely
annotations, with no run-time footprint, checked only by a static
analyzer that runs in the background; completely inconsistent with
type-checks in PHP.


Hm, that's a good point, I hadn't really thought about reflection. The 
general direction of my thoughts was to separate the concepts of "type" 
and "type constraint" - e.g. no value has the type "callable", but you 
can already constrain a parameter with the "callable" constraint. That 
fits nicely with things like union types, range / subset types, etc. But 
the more complex those constraints could be, the harder they'd be to 
represent with reflection...




Except that this proposal doesn't actually make the language consistently
type-checked. It adds a few more special cases where you can use type hints,
with slightly different behaviour.

That's not quite true.

With the addition of property type-hints, the public surface through
which you interact with objects would consistently support type-hints
- so at least that makes object interactions and class design a lot
more predictable.


I guess it's more a matter of opinion than truth. :) To me, a consistent 
typing system would be one that allows me to put type constraints 
wherever I have values. For instance, the current RFC excludes static 
properties, which as a user I consider to be close relatives of object 
properties, but to the engine are apparently more like plain variables. 
That's the kind of inconsistency that frustrates me, and makes the 
feature feel "half-baked", especially given that filling in the gaps is 
left as a "maybe, one day" rather than a "coming soon".




But at least we're finally there as far as objects, which in PHP is
probably the most important thing, as that's almost exclusively the
means by which we share code.


I'm not really convinced by this. I think the type system should be a 
feature of every part of the language, not just where it's convenient to 
fit it into the engine.




Indeed, "gradual typing" as defined by Jeremy Siek only really makes sense
in the context of static analysis.

Quoting Jeremy Siek: "Gradual typing allows software developers to
choose either type paradigm as appropriate, from within a single
language" - to me, that's the important thing about gradually-typed
languages.


Absolutely, we can import the goals of gradual typing. I just meant that 
the specific mechanism he described, of treating the "Any" type as 
"consistent with" every constraint, is a solution for writing static 
analysis tools, and doesn't help at run time, because there's never 
actually a value of the "Any" type.




Taking lots of little steps "towards" a goal that we've never even properly
defined is exactly what leads to *inconsistency* in the language.

I don't disagree with that, and I think that's a large part of PHP's problems.

But, on the other hand, we started down the road to gradual typing
when we started adding type-hints - whether we knew what we were doing
at the time or not, the next logical step down that road is property
type-hints, which will at least clear up the number one biggest
inconsistency as far as object and class design goes.


But we haven't ever decided what that road is, so how can we know what 
the next step is? What if we realise that the way we've implemented 
typed properties is completely at odds with the way we want to implement 
typed locals?




I think a number of people are not "anti-type-hints", they just don't agree
with this particular implementation.

Very possible, and they may be right - but I really hope these people
are doing something to help solve the problem, rather than simply
killing the idea and offering no alternative.


I agree, but I'd urge you to practice what you preach - don't despair 
that this vote didn't pass, engage with the people who voted against it, 
and work out how to make a proposal they'll approve. There's already a 
majority of voters, just not the required super-majority, so I think 
it's pretty clear that there's an appetite for the idea, if pushed in 
the right direction.


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Rasmus Schultz]

On Wed, Jun 22, 2016 at 7:44 PM, Rowan Collins  wrote:
>
> Out of curiosity, do these languages perform the type analysis at
> compilation, or at run-time? I'm trying to collate some examples of how
> other languages have approached the problem.

In Typescript, the type-hints are evaluated at compile-time only -
there is no run-time footprint at all, which is why they're actually
called "type annotations" in Typescript; they're just annotations
serving as directives for the compiler.

With Dart, you have a choice - you can actually toggle whether or no
type-checks should be performed at run-time. It's probably the best of
those two references, if you're looking for inspiration for PHP.

In PHP, every type-check is performed at run-time, and type-hints are
reflected - that's extremely important, and something Hack got
horribly wrong, as the type-hints they introduced are merely
annotations, with no run-time footprint, checked only by a static
analyzer that runs in the background; completely inconsistent with
type-checks in PHP.

>> PHP feels crippled on this point - it's gradually-typed,
>> but inconsistently so, and inconsistency is the worst kind of evil you
>> can have in any programming language.
>
> I absolutely agree, we need a plan for how to introduce a consistent gradual
> typing system. But this RFC is not that plan.

Maybe it's imperfect in it's current state, but it sounds to me like
it's pretty close?

The only serious issue I've had to point at, is the inconsistency
regarding references - but honestly, there are very (very) few reasons
to use references in the first place; there is usually a much better
solution with much less "wtf". (if I had to choose, honestly, I'd say
deprecate references.)

>> The learning curve for new users isn't increased by the introduction
>
> Except that this proposal doesn't actually make the language consistently
> type-checked. It adds a few more special cases where you can use type hints,
> with slightly different behaviour.

That's not quite true.

With the addition of property type-hints, the public surface through
which you interact with objects would consistently support type-hints
- so at least that makes object interactions and class design a lot
more predictable.

Yes, references are problem. Yes, type-hinted variables are a problem.
But at least we're finally there as far as objects, which in PHP is
probably the most important thing, as that's almost exclusively the
means by which we share code.

>> and then in addition they need to go and learn about
>> php-doc and offline inspection tools and IDEs and so forth.
>
> Interestingly, this is the direction that Hack and Python have both
> apparently chosen to enshrine - the syntax is baked into the language, but
> not actually enforced by the standard compiler or run-time in any way.
> Indeed, "gradual typing" as defined by Jeremy Siek only really makes sense
> in the context of static analysis.

Quoting Jeremy Siek: "Gradual typing allows software developers to
choose either type paradigm as appropriate, from within a single
language" - to me, that's the important thing about gradually-typed
languages.

Having worked with both Typescript and Dart, I can honestly say that I
never missed run-time type-checks in Typescript, but on the other
hand, I loved having reflection in Dart - I think it's not terribly
important which approach a language takes, as long as it's consistent.

PHP being a reflected and run-time type-checked language already,
there is not much of a choice here; especially being a reflected
language, having type-features that are available only in the context
of static analysis, such as in Hack, would be highly problematic. I
worked with Hack, briefly, and returned to PHP, one of the reasons
being, things like generics and property type-hints did not support
reflection, which meant that e.g. a reflection-based dependency
injection container cannot grow to support and exploit those aspects
of the language, which demonstrates why it's so important to be
consistent: in Typescript, I would not have started writing a
reflection-based DI container, because the language is not reflected,
but in Hack, being a continuation of PHP, I would have naturally
expected to continue in that direction.

> Taking lots of little steps "towards" a goal that we've never even properly
> defined is exactly what leads to *inconsistency* in the language.

I don't disagree with that, and I think that's a large part of PHP's problems.

But, on the other hand, we started down the road to gradual typing
when we started adding type-hints - whether we knew what we were doing
at the time or not, the next logical step down that road is property
type-hints, which will at least clear up the number one biggest
inconsistency as far as object and class design goes.

> I think a number of people are not "anti-type-hints", they just don't agree
> with this particular implementation.

Very possible, and they 

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Rowan Collins]

On 22/06/2016 16:58, Rasmus Schultz wrote:

On Wed, Jun 22, 2016 at 11:59 AM, Lester Caine  wrote:
Having worked in other gradually-typed languages like Dart and
Typescript


Out of curiosity, do these languages perform the type analysis at 
compilation, or at run-time? I'm trying to collate some examples of how 
other languages have approached the problem.




PHP feels crippled on this point - it's gradually-typed,
but inconsistently so, and inconsistency is the worst kind of evil you
can have in any programming language.


I absolutely agree, we need a plan for how to introduce a consistent 
gradual typing system. But this RFC is not that plan.





The learning curve for new users isn't increased by the introduction
of property type-hints, it's *decreased*


Except that this proposal doesn't actually make the language 
consistently type-checked. It adds a few more special cases where you 
can use type hints, with slightly different behaviour.


To carry on your imagined conversation:

- ooh, I can type-hint properties now!
- wait, what does this error mean? why would I not be able to assign 
this property by reference?
- oh, because the variable holding the reference would have to be 
type-hinted; how do I do that?

- oh, I can't...




and then in addition they need to go and learn about
php-doc and offline inspection tools and IDEs and so forth.


Interestingly, this is the direction that Hack and Python have both 
apparently chosen to enshrine - the syntax is baked into the language, 
but not actually enforced by the standard compiler or run-time in any 
way. Indeed, "gradual typing" as defined by Jeremy Siek only really 
makes sense in the context of static analysis.





Sorry, for the rant, but anti-type-hints is just anti-consistency. We
have type-hints, now let's please take another step towards finishing
the job!


Taking lots of little steps "towards" a goal that we've never even 
properly defined is exactly what leads to *inconsistency* in the language.


I think a number of people are not "anti-type-hints", they just don't 
agree with this particular implementation.


Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Michał Brzuchalski]

2016-06-22 18:49 GMT+02:00 Larry Garfield :

> On 06/22/2016 10:58 AM, Rasmus Schultz wrote:
>
>> The learning curve for new users isn't increased by the introduction
>> of property type-hints, it's *decreased*
>>
>
> I want to put that line on a plaque.  It applies for a lot of features
> being offered for PHP: They do actually make the language easier, not
> harder, by making the baseline language more consistent, robust, and
> coherent.
>
> The same argument can, and likely will, be made for native async; sure it
> *can* be done in userspace, but doing it in a standard way in the language
> will make it *easer*, not harder, to use PHP to its full potential.
>
> No, this is not true of every new language feature, but it is true of many
> of them.  The language needs to serve the ecosystem, not vice versa.
>
> --Larry Garfield
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I fully agree with Rasmus, I'm kind of developer complaining about the
missing PHP features.
At the same time often teach new programmers see their surprise and
embarrassment with lack of this functionality.

-- 
pozdrawiam
--
Michał Brzuchalski

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Larry Garfield]

On 06/22/2016 10:58 AM, Rasmus Schultz wrote:

The learning curve for new users isn't increased by the introduction
of property type-hints, it's *decreased*


I want to put that line on a plaque.  It applies for a lot of features 
being offered for PHP: They do actually make the language easier, not 
harder, by making the baseline language more consistent, robust, and 
coherent.


The same argument can, and likely will, be made for native async; sure 
it *can* be done in userspace, but doing it in a standard way in the 
language will make it *easer*, not harder, to use PHP to its full potential.


No, this is not true of every new language feature, but it is true of 
many of them.  The language needs to serve the ecosystem, not vice versa.


--Larry Garfield

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Christoph Becker]

On 22.06.2016 at 17:58, Rasmus Schultz wrote:

> Give them a consistent language and new developers will rise to the
> occasion - I'm sure of it. You're just not giving them a chance.
> Type-hinted properties are a step towards fixing that situation - they
> don't add, they *remove* complexity and learning curve from the
> language.
> 
> Consistency, when it comes to languages, is always simpler and less
> surprising than inconsistency.

ACK.

> PHP *has* type-checks - the introduction of property type-hints is not
> a new feature, it's fixing an inconsistency.

I'd argue that the current proposal brings new inconsistencies, namely
that you can type properties (besides already supported parameters), but
not other variables (okay, these are not properties, but still), no
static properties and there are restrictions regarding references to
typed properties.  In my opinion, these restrictions can be very
confusing for users – one already sufficient reason for me to abstain
from voting on a feature I'd like in principle.

-- 
Christoph M. Becker

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Rasmus Schultz]

On Wed, Jun 22, 2016 at 11:59 AM, Lester Caine  wrote:
>
> If all these other languages are so much better why is the usage of PHP
> *SO* much greater than any of them with no sign of any of them gaining
> traction?

I'm sorry, but that kind of rhetoric is really unproductive.

At no point did anyone suggest that type-checked properties was the
*only* difference between languages that matter - that would be
absurd.

All anyone is suggesting, is that it *does* matter - to argue that it
doesn't, solely based on what people are choosing, is silly. There are
many factors of choice.

I (along with most of my co-workers) yearn for a language-level
replacement for the ugly, unsafe, verbose php-doc tags everyone needs
to scatter around right now to get proper inspections about
property-types etc. - that yearning isn't driving me to another
language, because there are many other aspects to the language that I
enjoy, but it does remain on my top-10 list of the most desperately
missing features in PHP.

Having worked in other gradually-typed languages like Dart and
Typescript, PHP feels crippled on this point - it's gradually-typed,
but inconsistently so, and inconsistency is the worst kind of evil you
can have in any programming language.

New PHP developer:

- great, I can declare types like classes and interfaces!
- great, I can type-hint parameters!
- great, I can type-hint return-types!
- oh wait, how do I type-hint my properties...?
- oh. I can't.
- oh, there's tools for that.
- oh, tools only do half the job...

The learning curve for new users isn't increased by the introduction
of property type-hints, it's *decreased* - they have to learn about
types to write classes and interfaces, they have to learn about
type-hints when it comes to functions, but then, in addition, they
have to learn about the things they *can't* type-hint, for some
reason, not that anybody is offering an explanation, it's just a
matter of fact, and then in addition they need to go and learn about
php-doc and offline inspection tools and IDEs and so forth.

And a lot of developers are going to give up and resign themselves to
doing just what the language offers, long before learning all of that,
which could take them years, and in the mean time they write and
publish "newbie-looking" code, giving PHP developers a bad rep, lower
salaries, etc. - but it's not their fault, as most of them have a boss
asking them to produce code, now, and learning how to work around the
language to write good code takes a long time and a lot of effort for
most people. Meanwhile, skilled developers who went the extra mile are
out there complaining about these missing features in PHP.

Give them a consistent language and new developers will rise to the
occasion - I'm sure of it. You're just not giving them a chance.
Type-hinted properties are a step towards fixing that situation - they
don't add, they *remove* complexity and learning curve from the
language.

Consistency, when it comes to languages, is always simpler and less
surprising than inconsistency.

PHP *has* type-checks - the introduction of property type-hints is not
a new feature, it's fixing an inconsistency.

Sorry, for the rant, but anti-type-hints is just anti-consistency. We
have type-hints, now let's please take another step towards finishing
the job!

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Rowan Collins]

On 22/06/2016 10:37, Michał Brzuchalski wrote:

I may don't have voting privileges but as an 10yr PHP development
practitioner I can't believe that such big and awesome feature like Typed
Properties minimally can't have enought votes to be a part of PHP language
(26/(26+16) = 62% and that's not enoght to 2/3+1vote).


Bear in mind that this vote doesn't mean "PHP can never have typed 
properties", it means that "this particular approach to adding typed 
properties is not considered to be the right thing to do at the present 
time". If the vote had been unanimously against, it would have been hard 
to revive the proposal, but that's clearly not the case here.


I agree that type safety would be a good direction for the language to 
go in, but I think we need a decent plan for how exactly that would 
work, rather than adding piecemeal features that introduce awkward edge 
cases and unintended consequences. (The restriction on referencing typed 
properties is my go-to example of this.)


Incidentally, a crucial difference between PHP's type hints and those in 
just about any other language is that they are effectively assertions - 
dynamic, run-time checks (and sometimes implicit coercions) - rather 
than static, off-line analysis. You mentioned Java, which is a compiled 
language so provides full type safety at compile time; Python and Hack 
both consider type checks as metadata used by offline analysers, and 
ignore it at run-time. Perl6 I think does some run-time checking, but I 
couldn't find any documentation explicitly laying out the principles. 
That gives us a unique set of problems when designing them, not least in 
terms of performance.


Regards,
--
Rowan Collins
[IMSoP]



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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Michał Brzuchalski]

Hi,

According to my knowledge this path doesn't implement only string and int
types but whole of type hinting.
So your example usage of string and int maybe is unneded 'additional'
check, but in other cases where you expect objects which implements
specific inteface or class it's huge advantage when on runtime PHP checks
if specific property is set properly - has proper type.
Proper typed 'var' sure could be implemented in userland by complex type
checks in setters, but do we really need that setters/getters hell with
lots of `is_a`, `instanceof`, `class_implements` checks?
There's something I now for sure, observed this on voting for RFC's from
some time - if this path will be voted no there won't be any RFC with same
functionality in near future.
IMHO people writing RFC's and implementing patches they will not wanted to
provide another RFC's and another implementation.

Regards,
--
Michał Brzuchalski

2016-06-22 15:06 GMT+02:00 Marco Pivetta :

> Top-posting due to mobile conn.
>
> I voted no due to flaws introduced in the language by the current RFC.
>
> The performance impact is irrelevant.
> On Jun 22, 2016 11:38, "Michał Brzuchalski" 
> wrote:
>
>> Hi,
>>
>> I may don't have voting privileges but as an 10yr PHP development
>> practitioner I can't believe that such big and awesome feature like Typed
>> Properties minimally can't have enought votes to be a part of PHP language
>> (26/(26+16) = 62% and that's not enoght to 2/3+1vote).
>> There are plenty of places where type hinting actually exists and looks
>> like Typed Properties can be great complement of type system in PHP
>> language with the ability to still be so dynamic language as it is right
>> now.
>> The impact of 0.1% (or even more) of performance IMHO should not have no
>> significant meaning.
>> Someone earlier wrote that properties types should be ensured by
>> frameworks
>> - but that doesn't never happen, the impact on performance while
>> dynamically type checking inside setters would be few times greates than
>> this patch impact. Not to mention the fact that the feature itself
>> suggests
>> good practice.
>> Without it, we will still have setters/getters hell, and there will newer
>> be safe frameworks instad there will always be some hack's inside
>> subclasses or some other ways.
>> Without it, PHP will newer be aqualed such as Java, C# even Hack language
>> -
>> there still will continue to be a big gap, due to the lack of type
>> hinting.
>> Sure you could say start to code in Hack it has type safier system, it has
>> generics, annotations and other features which from time to time are in
>> PHP
>> RFC's but most of time they are declined and Hack lacks of great IDE
>> support like PHPStorm which I use and love because of refactor, code
>> styling, run etc.
>> PHP language has poor type safety and IMHO without such patches it will
>> never evolve into type safety programming language.
>>
>> Regards,
>> --
>> Michał Brzuchalski
>>
>> 2016-06-13 11:40 GMT+02:00 Joe Watkins :
>>
>> > Morning,
>> >
>> > > This wouldn't affect the performance of untyped properties at all.
>> >
>> > There are extra instructions in that code.
>> >
>> > When the code you have is only 5 instructions, adding 1 more instruction
>> > makes a 20% increase in instructions ...
>> >
>> > That is what we are looking at in these micro benchmarks; The number of
>> > instructions is so small, that even the small difference is measurable.
>> >
>> > Of course you can measure the difference, and obviously there are going
>> to
>> > be more instructions, but we should only care about what effects real
>> world
>> > code.
>> >
>> > This doesn't effect real world code.
>> >
>> > Cheers
>> > Joe
>> >
>> > On Sun, Jun 12, 2016 at 2:03 PM, Rasmus Schultz 
>> > wrote:
>> >
>> > > Pretend I know (basically) nothing about how PHP was implemented,
>> because
>> > > I don't ;-)
>> > >
>> > > But I don't understand why regular property updates should be
>> affected by
>> > > this at all?
>> > >
>> > > If I had to implement type-checked properties in plain PHP, I would do
>> > > something like this...
>> > >
>> > > /**
>> > >  * @property int $price
>> > >  */
>> > > class Product
>> > > {
>> > > private $_price;
>> > >
>> > > public function __set($name, $value) {
>> > > if ($name === "price") {
>> > > if (!is_int($value)) {
>> > > throw new UnexpectedValueException("...");
>> > > }
>> > > $this->_price = $price;
>> > > return;
>> > > }
>> > > throw new RuntimeException("undefined property {$name}");
>> > > }
>> > >
>> > > public function __get($name) {
>> > > return $this->{"_{$name}"};
>> > > }
>> > > }
>> > >
>> > > I would have guessed an implementation of type-checked properties
>> would
>> > > work in much the same way.
>> > >
>> > > Of course, it wouldn't use "_" as a 

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Marco Pivetta]

Top-posting due to mobile conn.

I voted no due to flaws introduced in the language by the current RFC.

The performance impact is irrelevant.
On Jun 22, 2016 11:38, "Michał Brzuchalski"  wrote:

> Hi,
>
> I may don't have voting privileges but as an 10yr PHP development
> practitioner I can't believe that such big and awesome feature like Typed
> Properties minimally can't have enought votes to be a part of PHP language
> (26/(26+16) = 62% and that's not enoght to 2/3+1vote).
> There are plenty of places where type hinting actually exists and looks
> like Typed Properties can be great complement of type system in PHP
> language with the ability to still be so dynamic language as it is right
> now.
> The impact of 0.1% (or even more) of performance IMHO should not have no
> significant meaning.
> Someone earlier wrote that properties types should be ensured by frameworks
> - but that doesn't never happen, the impact on performance while
> dynamically type checking inside setters would be few times greates than
> this patch impact. Not to mention the fact that the feature itself suggests
> good practice.
> Without it, we will still have setters/getters hell, and there will newer
> be safe frameworks instad there will always be some hack's inside
> subclasses or some other ways.
> Without it, PHP will newer be aqualed such as Java, C# even Hack language -
> there still will continue to be a big gap, due to the lack of type hinting.
> Sure you could say start to code in Hack it has type safier system, it has
> generics, annotations and other features which from time to time are in PHP
> RFC's but most of time they are declined and Hack lacks of great IDE
> support like PHPStorm which I use and love because of refactor, code
> styling, run etc.
> PHP language has poor type safety and IMHO without such patches it will
> never evolve into type safety programming language.
>
> Regards,
> --
> Michał Brzuchalski
>
> 2016-06-13 11:40 GMT+02:00 Joe Watkins :
>
> > Morning,
> >
> > > This wouldn't affect the performance of untyped properties at all.
> >
> > There are extra instructions in that code.
> >
> > When the code you have is only 5 instructions, adding 1 more instruction
> > makes a 20% increase in instructions ...
> >
> > That is what we are looking at in these micro benchmarks; The number of
> > instructions is so small, that even the small difference is measurable.
> >
> > Of course you can measure the difference, and obviously there are going
> to
> > be more instructions, but we should only care about what effects real
> world
> > code.
> >
> > This doesn't effect real world code.
> >
> > Cheers
> > Joe
> >
> > On Sun, Jun 12, 2016 at 2:03 PM, Rasmus Schultz 
> > wrote:
> >
> > > Pretend I know (basically) nothing about how PHP was implemented,
> because
> > > I don't ;-)
> > >
> > > But I don't understand why regular property updates should be affected
> by
> > > this at all?
> > >
> > > If I had to implement type-checked properties in plain PHP, I would do
> > > something like this...
> > >
> > > /**
> > >  * @property int $price
> > >  */
> > > class Product
> > > {
> > > private $_price;
> > >
> > > public function __set($name, $value) {
> > > if ($name === "price") {
> > > if (!is_int($value)) {
> > > throw new UnexpectedValueException("...");
> > > }
> > > $this->_price = $price;
> > > return;
> > > }
> > > throw new RuntimeException("undefined property {$name}");
> > > }
> > >
> > > public function __get($name) {
> > > return $this->{"_{$name}"};
> > > }
> > > }
> > >
> > > I would have guessed an implementation of type-checked properties would
> > > work in much the same way.
> > >
> > > Of course, it wouldn't use "_" as a prefix for the underlying property,
> > > but some other magic byte, much like how private properties are
> > internally
> > > prefixed with a magic byte, right?
> > >
> > > This wouldn't affect the performance of untyped properties at all.
> > >
> > > Of course typed property writes would be more expensive, but that's to
> be
> > > expected.
> > >
> > >
> > > On Sat, Jun 11, 2016 at 3:45 AM, Yasuo Ohgaki 
> > wrote:
> > >
> > >> Hi Dmitry,
> > >>
> > >> On Fri, Jun 10, 2016 at 9:37 PM, Dmitry Stogov 
> wrote:
> > >> > I hardly worked on implementation of this patch for a week, but I
> > still
> > >> don't like it.
> > >> >
> > >> > It makes 15% slowdown on each property update in existing PHP code
> > >> (without types), and I don't see a way to improve this.
> > >> >
> > >> > Update of typed properties is going to be even more expensive.
> > >> >
> > >> > Benchmark results are included into RFC (and not changed with the
> > >> latest version of the patch).
> > >> >
> > >> >
> > >> > -1.
> > >>
> > >> If we are concerned about performance, DbC would be the 

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Lester Caine]

On 22/06/16 11:25, Michał Brzuchalski wrote:
> Nobody will pursuade me not that type safety is nothing significant in
> programming language.

'type safety' is perhaps the problem here. In a compiled language you
are only ever passing a binary value for which the 'type' is a critical
element, but move away from the straight jacket of binary variables and
allow a user to type a number into a box and use that string value as a
variable then the 'type safety' needs to be implemented at the entry
point ... including checking the range of the number ... and so there is
no point adding code to every usage of a variable that has correctly
been validated already. Variables already stored will already have been
validated so again the 'additional' check that an integer is an integer
has little value?

Now start from a situation where we have a proper typed 'var' with the
ability to set constraints such as range or string length, then attempts
to store the wrong value can be handled ... something that several user
coded frameworks already provide ... then even the 'strict' debate has a
completely different base?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Michał Brzuchalski]

Hi,

I agree with you, but this patch does not result in any increase in
complexity - there still will be a way to declare non typed properties and
most of those developers wouldn't even fell any impact complexity on
development stage.
My goal is not to judge which language is better but to visualize loss for
the mass of developers will be the rejection of that patch.
Nobody will pursuade me not that type safety is nothing significant in
programming language.
According to "they are not degree level software engineers" I must
dissagree with you - they are less payed (their salary is 11%-15% less than
other mentioned language developers) also there is less great and huge
working projects/applications in the real life, most of engineering
colleges learn those other mentioned languages not PHP and there is also
never ending sneering war beetween PHP developers and those other mentioned.

Regards,
--
Michał Brzuchalski

2016-06-22 11:59 GMT+02:00 Lester Caine :

> On 22/06/16 10:37, Michał Brzuchalski wrote:
> > Without it, PHP will newer be aqualed such as Java, C# even Hack
> language -
> > there still will continue to be a big gap, due to the lack of type
> hinting.
> > Sure you could say start to code in Hack it has type safier system, it
> has
> > generics, annotations and other features which from time to time are in
> PHP
> > RFC's but most of time they are declined and Hack lacks of great IDE
> > support like PHPStorm which I use and love because of refactor, code
> > styling, run etc.
>
> If all these other languages are so much better why is the usage of PHP
> *SO* much greater than any of them with no sign of any of them gaining
> traction? Simply because for the vast number of users the simplicity of
> PHP works ... they are not degree level software engineers.
>
> --
> Lester Caine - G8HFL
> -
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
pozdrawiam
--
Michał Brzuchalski

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Lester Caine]

On 22/06/16 10:37, Michał Brzuchalski wrote:
> Without it, PHP will newer be aqualed such as Java, C# even Hack language -
> there still will continue to be a big gap, due to the lack of type hinting.
> Sure you could say start to code in Hack it has type safier system, it has
> generics, annotations and other features which from time to time are in PHP
> RFC's but most of time they are declined and Hack lacks of great IDE
> support like PHPStorm which I use and love because of refactor, code
> styling, run etc.

If all these other languages are so much better why is the usage of PHP
*SO* much greater than any of them with no sign of any of them gaining
traction? Simply because for the vast number of users the simplicity of
PHP works ... they are not degree level software engineers.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Michał Brzuchalski]

Hi,

I may don't have voting privileges but as an 10yr PHP development
practitioner I can't believe that such big and awesome feature like Typed
Properties minimally can't have enought votes to be a part of PHP language
(26/(26+16) = 62% and that's not enoght to 2/3+1vote).
There are plenty of places where type hinting actually exists and looks
like Typed Properties can be great complement of type system in PHP
language with the ability to still be so dynamic language as it is right
now.
The impact of 0.1% (or even more) of performance IMHO should not have no
significant meaning.
Someone earlier wrote that properties types should be ensured by frameworks
- but that doesn't never happen, the impact on performance while
dynamically type checking inside setters would be few times greates than
this patch impact. Not to mention the fact that the feature itself suggests
good practice.
Without it, we will still have setters/getters hell, and there will newer
be safe frameworks instad there will always be some hack's inside
subclasses or some other ways.
Without it, PHP will newer be aqualed such as Java, C# even Hack language -
there still will continue to be a big gap, due to the lack of type hinting.
Sure you could say start to code in Hack it has type safier system, it has
generics, annotations and other features which from time to time are in PHP
RFC's but most of time they are declined and Hack lacks of great IDE
support like PHPStorm which I use and love because of refactor, code
styling, run etc.
PHP language has poor type safety and IMHO without such patches it will
never evolve into type safety programming language.

Regards,
--
Michał Brzuchalski

2016-06-13 11:40 GMT+02:00 Joe Watkins :

> Morning,
>
> > This wouldn't affect the performance of untyped properties at all.
>
> There are extra instructions in that code.
>
> When the code you have is only 5 instructions, adding 1 more instruction
> makes a 20% increase in instructions ...
>
> That is what we are looking at in these micro benchmarks; The number of
> instructions is so small, that even the small difference is measurable.
>
> Of course you can measure the difference, and obviously there are going to
> be more instructions, but we should only care about what effects real world
> code.
>
> This doesn't effect real world code.
>
> Cheers
> Joe
>
> On Sun, Jun 12, 2016 at 2:03 PM, Rasmus Schultz 
> wrote:
>
> > Pretend I know (basically) nothing about how PHP was implemented, because
> > I don't ;-)
> >
> > But I don't understand why regular property updates should be affected by
> > this at all?
> >
> > If I had to implement type-checked properties in plain PHP, I would do
> > something like this...
> >
> > /**
> >  * @property int $price
> >  */
> > class Product
> > {
> > private $_price;
> >
> > public function __set($name, $value) {
> > if ($name === "price") {
> > if (!is_int($value)) {
> > throw new UnexpectedValueException("...");
> > }
> > $this->_price = $price;
> > return;
> > }
> > throw new RuntimeException("undefined property {$name}");
> > }
> >
> > public function __get($name) {
> > return $this->{"_{$name}"};
> > }
> > }
> >
> > I would have guessed an implementation of type-checked properties would
> > work in much the same way.
> >
> > Of course, it wouldn't use "_" as a prefix for the underlying property,
> > but some other magic byte, much like how private properties are
> internally
> > prefixed with a magic byte, right?
> >
> > This wouldn't affect the performance of untyped properties at all.
> >
> > Of course typed property writes would be more expensive, but that's to be
> > expected.
> >
> >
> > On Sat, Jun 11, 2016 at 3:45 AM, Yasuo Ohgaki 
> wrote:
> >
> >> Hi Dmitry,
> >>
> >> On Fri, Jun 10, 2016 at 9:37 PM, Dmitry Stogov  wrote:
> >> > I hardly worked on implementation of this patch for a week, but I
> still
> >> don't like it.
> >> >
> >> > It makes 15% slowdown on each property update in existing PHP code
> >> (without types), and I don't see a way to improve this.
> >> >
> >> > Update of typed properties is going to be even more expensive.
> >> >
> >> > Benchmark results are included into RFC (and not changed with the
> >> latest version of the patch).
> >> >
> >> >
> >> > -1.
> >>
> >> If we are concerned about performance, DbC would be the only solution
> >> for this kind of problem. i.e. Validate fully during development, do
> >> minimum validation on production. DbC helps type inference also. There
> >> may not be enough time for discussion, but do you think there is
> >> enough time for implementation? I suppose implementation is
> >> straightforward, so it might be OK to have RFC w/o implementation. We
> >> have 2 options anyway. It's waste of time for having 2
> >> implementations. Would you like to proceed the 

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Joe Watkins]

Morning,

> This wouldn't affect the performance of untyped properties at all.

There are extra instructions in that code.

When the code you have is only 5 instructions, adding 1 more instruction
makes a 20% increase in instructions ...

That is what we are looking at in these micro benchmarks; The number of
instructions is so small, that even the small difference is measurable.

Of course you can measure the difference, and obviously there are going to
be more instructions, but we should only care about what effects real world
code.

This doesn't effect real world code.

Cheers
Joe

On Sun, Jun 12, 2016 at 2:03 PM, Rasmus Schultz  wrote:

> Pretend I know (basically) nothing about how PHP was implemented, because
> I don't ;-)
>
> But I don't understand why regular property updates should be affected by
> this at all?
>
> If I had to implement type-checked properties in plain PHP, I would do
> something like this...
>
> /**
>  * @property int $price
>  */
> class Product
> {
> private $_price;
>
> public function __set($name, $value) {
> if ($name === "price") {
> if (!is_int($value)) {
> throw new UnexpectedValueException("...");
> }
> $this->_price = $price;
> return;
> }
> throw new RuntimeException("undefined property {$name}");
> }
>
> public function __get($name) {
> return $this->{"_{$name}"};
> }
> }
>
> I would have guessed an implementation of type-checked properties would
> work in much the same way.
>
> Of course, it wouldn't use "_" as a prefix for the underlying property,
> but some other magic byte, much like how private properties are internally
> prefixed with a magic byte, right?
>
> This wouldn't affect the performance of untyped properties at all.
>
> Of course typed property writes would be more expensive, but that's to be
> expected.
>
>
> On Sat, Jun 11, 2016 at 3:45 AM, Yasuo Ohgaki  wrote:
>
>> Hi Dmitry,
>>
>> On Fri, Jun 10, 2016 at 9:37 PM, Dmitry Stogov  wrote:
>> > I hardly worked on implementation of this patch for a week, but I still
>> don't like it.
>> >
>> > It makes 15% slowdown on each property update in existing PHP code
>> (without types), and I don't see a way to improve this.
>> >
>> > Update of typed properties is going to be even more expensive.
>> >
>> > Benchmark results are included into RFC (and not changed with the
>> latest version of the patch).
>> >
>> >
>> > -1.
>>
>> If we are concerned about performance, DbC would be the only solution
>> for this kind of problem. i.e. Validate fully during development, do
>> minimum validation on production. DbC helps type inference also. There
>> may not be enough time for discussion, but do you think there is
>> enough time for implementation? I suppose implementation is
>> straightforward, so it might be OK to have RFC w/o implementation. We
>> have 2 options anyway. It's waste of time for having 2
>> implementations. Would you like to proceed the RFC for 7.1?
>>
>> Regards,
>>
>> --
>> Yasuo Ohgaki
>> yohg...@ohgaki.net
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Lester Caine]

On 12/06/16 14:03, Rasmus Schultz wrote:
> If I had to implement type-checked properties in plain PHP, I would do
> something like this...
> 
> /**
>  * @property int $price
>  */
> class Product
> {
> private $_price;
> 
> public function __set($name, $value) {
> if ($name === "price") {
> if (!is_int($value)) {
> throw new UnexpectedValueException("...");
> }
> $this->_price = $price;
$this->_price = $value;
> return;
> }
> throw new RuntimeException("undefined property {$name}");
> }
> 
> public function __get($name) {
> return $this->{"_{$name}"};
> }
> }

I'm with you on not totally understanding the internals, but ...

var $_price;
Added code to handle the access restrictions, so checks have to be made
on just how $this->_price is accessed.
In my book, the __set function validates range as well as checking so
value is of the right type and any range error can be handled at the
right point. However if you add 'int' to the private then this now adds
a check to see if there IS a type restriction on the 'var' in addition
to access restriction.
Checks for 'strict' come in here as well?
But I still see a lot more cases where the 'is_int' checks are needed in
the normal flow prior to any ACTUAL assignment to the typed property. SO
it makes a lot more sense to me that '$this->_price = $value;' either
does the job of validation fully, or does not do it at all?
And there should be no distinction between $this->_price = $value; and
$this->params_array[_price] = $value; It is exactly the same variable?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Rasmus Schultz]

Pretend I know (basically) nothing about how PHP was implemented, because I
don't ;-)

But I don't understand why regular property updates should be affected by
this at all?

If I had to implement type-checked properties in plain PHP, I would do
something like this...

/**
 * @property int $price
 */
class Product
{
private $_price;

public function __set($name, $value) {
if ($name === "price") {
if (!is_int($value)) {
throw new UnexpectedValueException("...");
}
$this->_price = $price;
return;
}
throw new RuntimeException("undefined property {$name}");
}

public function __get($name) {
return $this->{"_{$name}"};
}
}

I would have guessed an implementation of type-checked properties would
work in much the same way.

Of course, it wouldn't use "_" as a prefix for the underlying property, but
some other magic byte, much like how private properties are internally
prefixed with a magic byte, right?

This wouldn't affect the performance of untyped properties at all.

Of course typed property writes would be more expensive, but that's to be
expected.


On Sat, Jun 11, 2016 at 3:45 AM, Yasuo Ohgaki  wrote:

> Hi Dmitry,
>
> On Fri, Jun 10, 2016 at 9:37 PM, Dmitry Stogov  wrote:
> > I hardly worked on implementation of this patch for a week, but I still
> don't like it.
> >
> > It makes 15% slowdown on each property update in existing PHP code
> (without types), and I don't see a way to improve this.
> >
> > Update of typed properties is going to be even more expensive.
> >
> > Benchmark results are included into RFC (and not changed with the latest
> version of the patch).
> >
> >
> > -1.
>
> If we are concerned about performance, DbC would be the only solution
> for this kind of problem. i.e. Validate fully during development, do
> minimum validation on production. DbC helps type inference also. There
> may not be enough time for discussion, but do you think there is
> enough time for implementation? I suppose implementation is
> straightforward, so it might be OK to have RFC w/o implementation. We
> have 2 options anyway. It's waste of time for having 2
> implementations. Would you like to proceed the RFC for 7.1?
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Thomas Bley]

Hi,

what about having "strict classes"?
A strict class would be like a database table, each property defined must have 
a type.
Each property defined must be initialized before being accessed, or have a 
default value.

e.g.
strict class Foo {
public int $id;
public bool $enabled;
public DateTime $created;
}

Regards
Thomas

Dmitry Stogov wrote on 10.06.2016 14:37:

> Hi,
> 
> 
> I hardly worked on implementation of this patch for a week, but I still don't
> like it.
> 
> It makes 15% slowdown on each property update in existing PHP code (without
> types), and I don't see a way to improve this.
> 
> Update of typed properties is going to be even more expensive.
> 
> Benchmark results are included into RFC (and not changed with the latest
> version of the patch).
> 
> 
> -1.
> 
> 
> Thanks. Dmitry.
> 
> 
> From: Joe Watkins <pthre...@pthreads.org>
> Sent: Friday, June 10, 2016 1:38:04 PM
> To: PHP internals; Phil Sturgeon
> Subject: [PHP-DEV] [RFC][Vote] Typed Properties
> 
> Afternoon internals,
> 
>The vote for typed properties has been restarted.
> 
>Please take part: https://wiki.php.net/rfc/typed-properties
> 
> Cheers
> Joe
> 


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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Yasuo Ohgaki]

Hi Dmitry,

On Fri, Jun 10, 2016 at 9:37 PM, Dmitry Stogov  wrote:
> I hardly worked on implementation of this patch for a week, but I still don't 
> like it.
>
> It makes 15% slowdown on each property update in existing PHP code (without 
> types), and I don't see a way to improve this.
>
> Update of typed properties is going to be even more expensive.
>
> Benchmark results are included into RFC (and not changed with the latest 
> version of the patch).
>
>
> -1.

If we are concerned about performance, DbC would be the only solution
for this kind of problem. i.e. Validate fully during development, do
minimum validation on production. DbC helps type inference also. There
may not be enough time for discussion, but do you think there is
enough time for implementation? I suppose implementation is
straightforward, so it might be OK to have RFC w/o implementation. We
have 2 options anyway. It's waste of time for having 2
implementations. Would you like to proceed the RFC for 7.1?

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Lester Caine]

On 10/06/16 22:05, Larry Garfield wrote:
> 
> https://seld.be/notes/php-versions-stats-2016-1-edition
> 
> The code being written is veering heavily toward newer versions, and
> anecdotally most of the code I see is classed with typed parameters. 
> (Yes, anecdotes are not data, and I acknowledged a likely bias earlier,
> but I'm not sure how to generate actually objective data on this
> front.)  That is arguably a more reliable measure of what developers are
> doing than the W3Techs stats, which are based on what servers are
> running.  (A useful but different metric.)

The problem with your base is it assumes everybody is using composer?
Just how many people are not? None of my infrastructure uses it and none
of the ISP's I support. So it's skewed in favour of the converted.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Larry Garfield]

On 06/10/2016 03:01 PM, Lester Caine wrote:

On 10/06/16 20:51, Larry Garfield wrote:

On 06/10/2016 02:14 PM, Lester Caine wrote:

On 10/06/16 17:57, Rowan Collins wrote:

For the record, I'm not entirely sure which way I want the language to
go, but I think it's a decision that needs to be made, and soon.

Seconded ... even something like strict mode should be 'removable' to
provide a smaller faster 'classic' PHP even if it does mean there are
two builds. But we already HAVE two builds ... people who want strongly
typed and pre-compiled PHP simply use HHVM. There is no need to drag PHP
down the same road map? Each has it's own strengths.

... I am a strong typing proponent (that is a strong proponent of
explicit typing), and have never once used HHVM.  Your claim, that
type-using people can just leave for HHVM, is both nonsensical and untrue.

The same applies to your suggestion that user-land is actively following
you. Getting systems off PHP5.2/3 gets more an more difficult given all
the extra 'little tweaks' that are needed and we still have 40% of users
that need help getting just over to 5.4 let alone up to PHP7. Currently
more people are still using PHP4 than have switched to PHP7 ... so where
is the strong support for typed code?

(https://w3techs.com/technologies/details/pl-php/all/all)


https://seld.be/notes/php-versions-stats-2016-1-edition

The code being written is veering heavily toward newer versions, and 
anecdotally most of the code I see is classed with typed parameters.  
(Yes, anecdotes are not data, and I acknowledged a likely bias earlier, 
but I'm not sure how to generate actually objective data on this 
front.)  That is arguably a more reliable measure of what developers are 
doing than the W3Techs stats, which are based on what servers are 
running.  (A useful but different metric.)


--Larry Garfield

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Lester Caine]

On 10/06/16 20:51, Larry Garfield wrote:
> On 06/10/2016 02:14 PM, Lester Caine wrote:
>> On 10/06/16 17:57, Rowan Collins wrote:
>>> For the record, I'm not entirely sure which way I want the language to
>>> go, but I think it's a decision that needs to be made, and soon.
>> Seconded ... even something like strict mode should be 'removable' to
>> provide a smaller faster 'classic' PHP even if it does mean there are
>> two builds. But we already HAVE two builds ... people who want strongly
>> typed and pre-compiled PHP simply use HHVM. There is no need to drag PHP
>> down the same road map? Each has it's own strengths.
> 
> ... I am a strong typing proponent (that is a strong proponent of
> explicit typing), and have never once used HHVM.  Your claim, that
> type-using people can just leave for HHVM, is both nonsensical and untrue.

The same applies to your suggestion that user-land is actively following
you. Getting systems off PHP5.2/3 gets more an more difficult given all
the extra 'little tweaks' that are needed and we still have 40% of users
that need help getting just over to 5.4 let alone up to PHP7. Currently
more people are still using PHP4 than have switched to PHP7 ... so where
is the strong support for typed code?

(https://w3techs.com/technologies/details/pl-php/all/all)

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Larry Garfield]

On 06/10/2016 02:14 PM, Lester Caine wrote:

On 10/06/16 17:57, Rowan Collins wrote:

For the record, I'm not entirely sure which way I want the language to
go, but I think it's a decision that needs to be made, and soon.

Seconded ... even something like strict mode should be 'removable' to
provide a smaller faster 'classic' PHP even if it does mean there are
two builds. But we already HAVE two builds ... people who want strongly
typed and pre-compiled PHP simply use HHVM. There is no need to drag PHP
down the same road map? Each has it's own strengths.


... I am a strong typing proponent (that is a strong proponent of 
explicit typing), and have never once used HHVM.  Your claim, that 
type-using people can just leave for HHVM, is both nonsensical and untrue.


--Larry Garfield

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Lester Caine]

On 10/06/16 17:57, Rowan Collins wrote:
> 
> For the record, I'm not entirely sure which way I want the language to
> go, but I think it's a decision that needs to be made, and soon.

Seconded ... even something like strict mode should be 'removable' to
provide a smaller faster 'classic' PHP even if it does mean there are
two builds. But we already HAVE two builds ... people who want strongly
typed and pre-compiled PHP simply use HHVM. There is no need to drag PHP
down the same road map? Each has it's own strengths.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Larry Garfield]

On 06/10/2016 11:57 AM, Rowan Collins wrote:

On 10/06/2016 17:16, Larry Garfield wrote:

That seems like a worthwhile trade-off for a <1% performance difference
in a real-world application.


The problem is that the performance hit is felt even for code that 
doesn't "opt in" to this feature. For an application that makes no use 
of the feature, it is all cost and no benefit.


I think PHP is at a cross-roads, and (if you'll forgive the stretched 
analogy) at risk of going off-road and getting stuck in the mud.


Option 1 is that the language remains inherently loose-typed, with a 
few entirely optional features to provide type safety in specific 
cases. If this is the aim, then the optional features should be as 
unobtrusive as possible for the "default" loose-typed approach. Any 
performance hit on untyped properties is a big deal under this 
interpretation.


Option 2 is that the language embraces "gradual typing" as a core 
tenet of the language, with loose typing considered a "fallback". If 
this is the aim, then there should be a coherent roadmap of what the 
type system is going to look like. In this case, performance issues 
might be considered an inevitable cost of improving the language; they 
might also be reduced as the Engine is adapted to implement the roadmap.


Option 1 seems more appealing, because it is easier to get agreement 
for, but if we keep piling on the special cases, we're going to end up 
with the worst of both worlds. I see the technical problems with 
creating a reference to a typed property as a sign of this: we are 
creating more of the frustrating inconsistencies that PHP is infamous 
for, because we're trying to have our cake and eat it.


For the record, I'm not entirely sure which way I want the language to 
go, but I think it's a decision that needs to be made, and soon.


Regards,


This is a very accurate and well-stated assessment.  I agree with the 
possible paths.


From the code I see in the wild, it feels like the gradually/mostly 
typed camp has already won in terms of production code.  Most of the PHP 
Rennaissance-era systems (the stuff that came out in the last 5-6 years 
or so) is class-heavy and as type safe as PHP has allowed, most of the 
time.  The exceptions are the highly functional bits, where the language 
doesn't offer as much support as it does for class-family typing.


There's almost certainly some projecting going on here as I'm a 
mostly-typed fan myself, but my sense is that the PHP user-space 
community has already decided they want a robust typing system they can 
use in most (but not all) cases.  The engine should embrace that and 
catch up, with a well thought-out approach to typing.  If it takes a bit 
longer to get certain features as a result of that attention to a 
coherent roadmap, I am happy to make that trade-off.


--Larry Garfield

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Rowan Collins]

On 10/06/2016 17:16, Larry Garfield wrote:

That seems like a worthwhile trade-off for a <1% performance difference
in a real-world application.


The problem is that the performance hit is felt even for code that 
doesn't "opt in" to this feature. For an application that makes no use 
of the feature, it is all cost and no benefit.


I think PHP is at a cross-roads, and (if you'll forgive the stretched 
analogy) at risk of going off-road and getting stuck in the mud.


Option 1 is that the language remains inherently loose-typed, with a few 
entirely optional features to provide type safety in specific cases. If 
this is the aim, then the optional features should be as unobtrusive as 
possible for the "default" loose-typed approach. Any performance hit on 
untyped properties is a big deal under this interpretation.


Option 2 is that the language embraces "gradual typing" as a core tenet 
of the language, with loose typing considered a "fallback". If this is 
the aim, then there should be a coherent roadmap of what the type system 
is going to look like. In this case, performance issues might be 
considered an inevitable cost of improving the language; they might also 
be reduced as the Engine is adapted to implement the roadmap.


Option 1 seems more appealing, because it is easier to get agreement 
for, but if we keep piling on the special cases, we're going to end up 
with the worst of both worlds. I see the technical problems with 
creating a reference to a typed property as a sign of this: we are 
creating more of the frustrating inconsistencies that PHP is infamous 
for, because we're trying to have our cake and eat it.


For the record, I'm not entirely sure which way I want the language to 
go, but I think it's a decision that needs to be made, and soon.


Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Larry Garfield]

On 06/10/2016 10:01 AM, Dmitry Stogov wrote:



To clarify though, didn't Wordpress and Mediawiki see only a 0.1%
slowdown? In my opinion that is definitely a tolerable performance hit
for such a feature.

I don't see any big value in this feature.
Most framework access their properties through getters and setters 
anyway.

They can be and should be used to provide type-safe API.
Another level of protection that makes slowdown instead of expected 
speedup, doesn't make any sense for me.


Thanks. Dmitry.


Needing an explicit getter and setter (and the overhead of the function 
call) just for type checking is a bug this feature would obviate.  If 
the only value of the getter/setter is type safety, then you're better 
off not using them.  (There are other reasons to have getters and 
setters, and I'd still love to see the property accessor RFC reborn, but 
that's a separate issue.)


Additionally, typed properties provides a terser, more self-documenting 
way of communicating the property type and thus expected behavior.  I've 
written several doctrine classes, for instance, that are 5 lines of 
properties and 30 lines of getters/setters/docs boilerplate.  If that 
boilerplate can be reduced or eliminated, that's a win.


It also provides better introspection capabilities for ORMs and similar 
serialization tools.  Yes, in some cases richer data than this RFC 
provides is helpful but not always.  In many cases this would be 
sufficient to build automated safety into automated tools. (ORMs, 
serializers, validators that now don't need to be written at all, etc.)


That seems like a worthwhile trade-off for a <1% performance difference 
in a real-world application.


--Larry Garfield

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Dmitry Stogov]

On 06/10/2016 05:31 PM, Bob Weinand wrote:

Am 10.06.2016 um 16:24 schrieb Levi Morrison <le...@php.net>:

On Fri, Jun 10, 2016 at 6:37 AM, Dmitry Stogov <dmi...@zend.com> wrote:

Hi,


I hardly worked on implementation of this patch for a week, but I still don't 
like it.

It makes 15% slowdown on each property update in existing PHP code (without 
types), and I don't see a way to improve this.

Update of typed properties is going to be even more expensive.

Benchmark results are included into RFC (and not changed with the latest 
version of the patch).


-1.


Thanks. Dmitry.


From: Joe Watkins <pthre...@pthreads.org>
Sent: Friday, June 10, 2016 1:38:04 PM
To: PHP internals; Phil Sturgeon
Subject: [PHP-DEV] [RFC][Vote] Typed Properties

Afternoon internals,

The vote for typed properties has been restarted.

Please take part: https://wiki.php.net/rfc/typed-properties

Cheers
Joe

To clarify though, didn't Wordpress and Mediawiki see only a 0.1%
slowdown? In my opinion that is definitely a tolerable performance hit
for such a feature.

Right, the 15% are quite skewed … it's in a tight loop which means ideal L1 
cache utilization and the number of executed instructions for a runtime-cached 
ASSIGN_OBJ is very small. Where even 4 additional instructions make significant 
difference.
The current fast-path of ASSIGN_DIM is about 40 instruction, so 15% 
slowdown comes exactly from this additional 4 instructions and 
additional memory read.



The 0.1% slowdown of WP and MW are painting a much more realistic (aka real-world) image. 
And as the RFC writes, "may be caused not by the additional checks but by the worse 
CPU cache utilization, because the size of PHP code was increased on 40KB".


Yes, this is my words :)
  
These micro-benches are really insignificant, especially as it is trivial (in tight loops) to work on a local CV and only assign it later to the property.
they show the effect of the patch on the affected operations, and the 
shown slowdown is significant.
Of course this doesn't affect WP significantly, because the whole 
ASSIGN_OBJ cost in the app is less than 1%.

So  we slowdown this ~1% on ~15% and got ~0.1% cumulative slowdown.

Thanks. Dmitry.



This IMO is really voting no for the wrong reasons...

Bob



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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Dmitry Stogov]

On 06/10/2016 05:24 PM, Levi Morrison wrote:

On Fri, Jun 10, 2016 at 6:37 AM, Dmitry Stogov 
<dmi...@zend.com><mailto:dmi...@zend.com> wrote:


Hi,


I hardly worked on implementation of this patch for a week, but I still don't 
like it.

It makes 15% slowdown on each property update in existing PHP code (without 
types), and I don't see a way to improve this.

Update of typed properties is going to be even more expensive.

Benchmark results are included into RFC (and not changed with the latest 
version of the patch).


-1.


Thanks. Dmitry.


From: Joe Watkins <pthre...@pthreads.org><mailto:pthre...@pthreads.org>
Sent: Friday, June 10, 2016 1:38:04 PM
To: PHP internals; Phil Sturgeon
Subject: [PHP-DEV] [RFC][Vote] Typed Properties

Afternoon internals,

The vote for typed properties has been restarted.

Please take part: https://wiki.php.net/rfc/typed-properties

Cheers
Joe


To clarify though, didn't Wordpress and Mediawiki see only a 0.1%
slowdown? In my opinion that is definitely a tolerable performance hit
for such a feature.


I don't see any big value in this feature.
Most framework access object properties through getters and setters anyway.
They can be and should be used to provide type-safe API.
Another level of protection that makes slowdown instead of expected speedup, 
dosn't make any sense.


Thanks. Dmitry.

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Dmitry Stogov]

On 06/10/2016 05:24 PM, Levi Morrison wrote:

On Fri, Jun 10, 2016 at 6:37 AM, Dmitry Stogov <dmi...@zend.com> wrote:

Hi,


I hardly worked on implementation of this patch for a week, but I still don't 
like it.

It makes 15% slowdown on each property update in existing PHP code (without 
types), and I don't see a way to improve this.

Update of typed properties is going to be even more expensive.

Benchmark results are included into RFC (and not changed with the latest 
version of the patch).


-1.


Thanks. Dmitry.


From: Joe Watkins <pthre...@pthreads.org>
Sent: Friday, June 10, 2016 1:38:04 PM
To: PHP internals; Phil Sturgeon
Subject: [PHP-DEV] [RFC][Vote] Typed Properties

Afternoon internals,

 The vote for typed properties has been restarted.

 Please take part: https://wiki.php.net/rfc/typed-properties

Cheers
Joe

To clarify though, didn't Wordpress and Mediawiki see only a 0.1%
slowdown? In my opinion that is definitely a tolerable performance hit
for such a feature.

I don't see any big value in this feature.
Most framework access their properties through getters and setters anyway.
They can be and should be used to provide type-safe API.
Another level of protection that makes slowdown instead of expected 
speedup, doesn't make any sense for me.


Thanks. Dmitry.



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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Joe Watkins]

Woops, no it isn't ... the property is private ...

Cheers
Joe

On Fri, Jun 10, 2016 at 3:42 PM, Joe Watkins  wrote:

> That's a bug ... that should throw ...
>
> Cheers
> Joe
>
> On Fri, Jun 10, 2016 at 3:12 PM, Bob Weinand  wrote:
>
>>
>> Am 10.06.2016 um 16:00 schrieb Niklas Keller :
>>
>> 2016-06-10 15:50 GMT+02:00 Bob Weinand :
>>
>>>
>>> Am 10.6.2016 um 15:34 schrieb Niklas Keller :
>>>
>>>
>>> Top-posting, since I'm taking off now.
>>>
>>> From outside the class, properties are not visible at all, so their types
>>> are un-important from outer scopes.
>>>
>>> echo $foo->bar; is not the same in instance method body or outside of the
>>> class.
>>>
>>> From outside it works just fine and doesn't throw:
>>> https://3v4l.org/L8CqF/rfc#rfc-typed_properties
>>>
>>>
>>> This is an intermittent bug in the implementation.
>>> the RFC is explicitly mentioning that it should throw and throwing also
>>> is the correct behavior here.
>>>
>>
>> I don't think this is and should be a bug. I think it is the right
>> behavior if we choose to throw at all.
>>
>>
>> In this case a definite -1 on the RFC from me. I don't want "surprises"
>> regarding the type if a property is declared to return a certain type.
>>
>> Bob
>>
>
>

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Joe Watkins]

That's a bug ... that should throw ...

Cheers
Joe

On Fri, Jun 10, 2016 at 3:12 PM, Bob Weinand  wrote:

>
> Am 10.06.2016 um 16:00 schrieb Niklas Keller :
>
> 2016-06-10 15:50 GMT+02:00 Bob Weinand :
>
>>
>> Am 10.6.2016 um 15:34 schrieb Niklas Keller :
>>
>>
>> Top-posting, since I'm taking off now.
>>
>> From outside the class, properties are not visible at all, so their types
>> are un-important from outer scopes.
>>
>> echo $foo->bar; is not the same in instance method body or outside of the
>> class.
>>
>> From outside it works just fine and doesn't throw:
>> https://3v4l.org/L8CqF/rfc#rfc-typed_properties
>>
>>
>> This is an intermittent bug in the implementation.
>> the RFC is explicitly mentioning that it should throw and throwing also
>> is the correct behavior here.
>>
>
> I don't think this is and should be a bug. I think it is the right
> behavior if we choose to throw at all.
>
>
> In this case a definite -1 on the RFC from me. I don't want "surprises"
> regarding the type if a property is declared to return a certain type.
>
> Bob
>

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Bob Weinand]

> Am 10.06.2016 um 16:24 schrieb Levi Morrison <le...@php.net>:
> 
> On Fri, Jun 10, 2016 at 6:37 AM, Dmitry Stogov <dmi...@zend.com> wrote:
>> Hi,
>> 
>> 
>> I hardly worked on implementation of this patch for a week, but I still 
>> don't like it.
>> 
>> It makes 15% slowdown on each property update in existing PHP code (without 
>> types), and I don't see a way to improve this.
>> 
>> Update of typed properties is going to be even more expensive.
>> 
>> Benchmark results are included into RFC (and not changed with the latest 
>> version of the patch).
>> 
>> 
>> -1.
>> 
>> 
>> Thanks. Dmitry.
>> 
>> ____________
>> From: Joe Watkins <pthre...@pthreads.org>
>> Sent: Friday, June 10, 2016 1:38:04 PM
>> To: PHP internals; Phil Sturgeon
>> Subject: [PHP-DEV] [RFC][Vote] Typed Properties
>> 
>> Afternoon internals,
>> 
>>The vote for typed properties has been restarted.
>> 
>>Please take part: https://wiki.php.net/rfc/typed-properties
>> 
>> Cheers
>> Joe
> 
> To clarify though, didn't Wordpress and Mediawiki see only a 0.1%
> slowdown? In my opinion that is definitely a tolerable performance hit
> for such a feature.

Right, the 15% are quite skewed … it's in a tight loop which means ideal L1 
cache utilization and the number of executed instructions for a runtime-cached 
ASSIGN_OBJ is very small. Where even 4 additional instructions make significant 
difference.
The 0.1% slowdown of WP and MW are painting a much more realistic (aka 
real-world) image. And as the RFC writes, "may be caused not by the additional 
checks but by the worse CPU cache utilization, because the size of PHP code was 
increased on 40KB". 
These micro-benches are really insignificant, especially as it is trivial (in 
tight loops) to work on a local CV and only assign it later to the property.

This IMO is really voting no for the wrong reasons...

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Levi Morrison]

On Fri, Jun 10, 2016 at 6:37 AM, Dmitry Stogov <dmi...@zend.com> wrote:
> Hi,
>
>
> I hardly worked on implementation of this patch for a week, but I still don't 
> like it.
>
> It makes 15% slowdown on each property update in existing PHP code (without 
> types), and I don't see a way to improve this.
>
> Update of typed properties is going to be even more expensive.
>
> Benchmark results are included into RFC (and not changed with the latest 
> version of the patch).
>
>
> -1.
>
>
> Thanks. Dmitry.
>
> 
> From: Joe Watkins <pthre...@pthreads.org>
> Sent: Friday, June 10, 2016 1:38:04 PM
> To: PHP internals; Phil Sturgeon
> Subject: [PHP-DEV] [RFC][Vote] Typed Properties
>
> Afternoon internals,
>
> The vote for typed properties has been restarted.
>
> Please take part: https://wiki.php.net/rfc/typed-properties
>
> Cheers
> Joe

To clarify though, didn't Wordpress and Mediawiki see only a 0.1%
slowdown? In my opinion that is definitely a tolerable performance hit
for such a feature.

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Bob Weinand]

> Am 10.06.2016 um 16:16 schrieb Niklas Keller :
> 
> 
> 2016-06-10 16:12 GMT+02:00 Bob Weinand  >:
> In this case a definite -1 on the RFC from me. I don't want "surprises" 
> regarding the type if a property is declared to return a certain type.
> 
> Where's the surprise?

Receiving a different type than I asked for. (as promised by the type decl)

Bob

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Niklas Keller]

2016-06-10 16:12 GMT+02:00 Bob Weinand :

> In this case a definite -1 on the RFC from me. I don't want "surprises"
> regarding the type if a property is declared to return a certain type.
>

Where's the surprise?

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Bob Weinand]

> Am 10.06.2016 um 16:00 schrieb Niklas Keller :
> 
> 2016-06-10 15:50 GMT+02:00 Bob Weinand  >:
> 
>> Am 10.6.2016 um 15:34 schrieb Niklas Keller > >:
>> 
>>> 
>>> Top-posting, since I'm taking off now.
>>> 
>>> From outside the class, properties are not visible at all, so their types
>>> are un-important from outer scopes.
>>> 
>>> echo $foo->bar; is not the same in instance method body or outside of the
>>> class.
>>> 
>> From outside it works just fine and doesn't throw:
>> https://3v4l.org/L8CqF/rfc#rfc-typed_properties 
>> 
> 
> This is an intermittent bug in the implementation.
> the RFC is explicitly mentioning that it should throw and throwing also is 
> the correct behavior here.
> 
> I don't think this is and should be a bug. I think it is the right behavior 
> if we choose to throw at all. 

In this case a definite -1 on the RFC from me. I don't want "surprises" 
regarding the type if a property is declared to return a certain type.

Bob

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Niklas Keller]

2016-06-10 15:50 GMT+02:00 Bob Weinand :

>
> Am 10.6.2016 um 15:34 schrieb Niklas Keller :
>
>
> Top-posting, since I'm taking off now.
>
> From outside the class, properties are not visible at all, so their types
> are un-important from outer scopes.
>
> echo $foo->bar; is not the same in instance method body or outside of the
> class.
>
> From outside it works just fine and doesn't throw:
> https://3v4l.org/L8CqF/rfc#rfc-typed_properties
>
>
> This is an intermittent bug in the implementation.
> the RFC is explicitly mentioning that it should throw and throwing also is
> the correct behavior here.
>

I don't think this is and should be a bug. I think it is the right behavior
if we choose to throw at all.

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Bob Weinand]

> Am 10.6.2016 um 15:34 schrieb Niklas Keller :
> 
>> 
>> Top-posting, since I'm taking off now.
>> 
>> From outside the class, properties are not visible at all, so their types
>> are un-important from outer scopes.
>> 
>> echo $foo->bar; is not the same in instance method body or outside of the
>> class.
>> 
> From outside it works just fine and doesn't throw:
> https://3v4l.org/L8CqF/rfc#rfc-typed_properties

This is an intermittent bug in the implementation.
the RFC is explicitly mentioning that it should throw and throwing also is the 
correct behavior here.

Bob

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Niklas Keller]

>
> Top-posting, since I'm taking off now.
>
> From outside the class, properties are not visible at all, so their types
> are un-important from outer scopes.
>
> echo $foo->bar; is not the same in instance method body or outside of the
> class.
>
>From outside it works just fine and doesn't throw:
https://3v4l.org/L8CqF/rfc#rfc-typed_properties

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Marco Pivetta]

Top-posting, since I'm taking off now.

>From outside the class, properties are not visible at all, so their types
are un-important from outer scopes.

echo $foo->bar; is not the same in instance method body or outside of the
class.
On Jun 10, 2016 2:55 PM, "Niklas Keller"  wrote:

> 2016-06-10 14:39 GMT+02:00 Marco Pivetta :
>
>> As already mentioned on twitter, I voted "no" on this RFC as it currently
>> stands. I might reconsider if following points are addressed:
>>
>>  1. __get semantics are not changed: let __get behave like it usually
>> does,
>> and let the user define a type hint on __get, should any be applicable.
>> Basically:
>>
>> class Foo
>> {
>> private int $bar = 123;
>> public function __get($name) { return 'banana'; } // *ALWAYS* works -
>> why would I even want a type error here?
>> }
>>
>
> You want a type error if bar is unset, mainly because Foo->bar should
> always be an int.
> If you unset it and set it again, it still has to be an int. And
> reflection will tell you it's always an int.
> So why should __get be allowed to return something different?
>
>
>>  * by-ref access should be enabled when the reference property has the
>> same
>> declared type as the source one
>>
>> class Foo
>> {
>> public int $bar = 123;
>> }
>>
>> class Bar
>> {
>> public int $baz = 456;
>> public string $taz = 'taz';
>> }
>>
>> $foo = new Foo;
>> $bar = new Bar;
>>
>> $bar->baz = & $foo->bar; // works
>> $bar->taz = & $foo->bar; // crashes
>>
>> Cheers,
>>
>>
>> Marco Pivetta
>>
>> http://twitter.com/Ocramius
>>
>> http://ocramius.github.com/
>>
>> On 10 June 2016 at 12:38, Joe Watkins  wrote:
>>
>> > Afternoon internals,
>> >
>> > The vote for typed properties has been restarted.
>> >
>> > Please take part: https://wiki.php.net/rfc/typed-properties
>> >
>> > Cheers
>> > Joe
>> >
>>
>
>

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Niklas Keller]

2016-06-10 14:39 GMT+02:00 Marco Pivetta :

> As already mentioned on twitter, I voted "no" on this RFC as it currently
> stands. I might reconsider if following points are addressed:
>
>  1. __get semantics are not changed: let __get behave like it usually does,
> and let the user define a type hint on __get, should any be applicable.
> Basically:
>
> class Foo
> {
> private int $bar = 123;
> public function __get($name) { return 'banana'; } // *ALWAYS* works -
> why would I even want a type error here?
> }
>

You want a type error if bar is unset, mainly because Foo->bar should
always be an int.
If you unset it and set it again, it still has to be an int. And reflection
will tell you it's always an int.
So why should __get be allowed to return something different?


>  * by-ref access should be enabled when the reference property has the same
> declared type as the source one
>
> class Foo
> {
> public int $bar = 123;
> }
>
> class Bar
> {
> public int $baz = 456;
> public string $taz = 'taz';
> }
>
> $foo = new Foo;
> $bar = new Bar;
>
> $bar->baz = & $foo->bar; // works
> $bar->taz = & $foo->bar; // crashes
>
> Cheers,
>
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
> On 10 June 2016 at 12:38, Joe Watkins  wrote:
>
> > Afternoon internals,
> >
> > The vote for typed properties has been restarted.
> >
> > Please take part: https://wiki.php.net/rfc/typed-properties
> >
> > Cheers
> > Joe
> >
>

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Marco Pivetta]

As already mentioned on twitter, I voted "no" on this RFC as it currently
stands. I might reconsider if following points are addressed:

 1. __get semantics are not changed: let __get behave like it usually does,
and let the user define a type hint on __get, should any be applicable.
Basically:

class Foo
{
private int $bar = 123;
public function __get($name) { return 'banana'; } // *ALWAYS* works -
why would I even want a type error here?
}

 * by-ref access should be enabled when the reference property has the same
declared type as the source one

class Foo
{
public int $bar = 123;
}

class Bar
{
public int $baz = 456;
public string $taz = 'taz';
}

$foo = new Foo;
$bar = new Bar;

$bar->baz = & $foo->bar; // works
$bar->taz = & $foo->bar; // crashes

Cheers,


Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On 10 June 2016 at 12:38, Joe Watkins  wrote:

> Afternoon internals,
>
> The vote for typed properties has been restarted.
>
> Please take part: https://wiki.php.net/rfc/typed-properties
>
> Cheers
> Joe
>

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Dmitry Stogov]

Hi,


I hardly worked on implementation of this patch for a week, but I still don't 
like it.

It makes 15% slowdown on each property update in existing PHP code (without 
types), and I don't see a way to improve this.

Update of typed properties is going to be even more expensive.

Benchmark results are included into RFC (and not changed with the latest 
version of the patch).


-1.


Thanks. Dmitry.


From: Joe Watkins <pthre...@pthreads.org>
Sent: Friday, June 10, 2016 1:38:04 PM
To: PHP internals; Phil Sturgeon
Subject: [PHP-DEV] [RFC][Vote] Typed Properties

Afternoon internals,

The vote for typed properties has been restarted.

Please take part: https://wiki.php.net/rfc/typed-properties

Cheers
Joe

[PHP-DEV] [RFC][Vote] Typed Properties

[Joe Watkins]

Afternoon internals,

The vote for typed properties has been restarted.

Please take part: https://wiki.php.net/rfc/typed-properties

Cheers
Joe

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Lester Caine]

On 28/05/16 09:06, Lester Caine wrote:
> class Person {
>   protected var $death; // var is intentional - my flag for a holder
>   $death->__type( DateTime, not_null = false );
> 
> To which one can add
>   $death->__limit( $birth, '120years' );
> Where $birth now has to be the same type and '120years' gets magically
> converted to a date offset :)

Adding that 'var' seemed totally natural as I wrote it. I could not
understand why at the time, but having slept on it, the reason has is
obvious. 'DateTime' can't be 'null' and any attempt to set it to such
will give you 'now' instead. BUT we have demonstrated (hopefully) that
we do need null dates, so we need a container that can either be null or
a date ... sounds suspiciously like good old var?

Now access to 'var' needs an attribute which can be
'public,private,protected' .. . but also 'read only' ( I'll ignore
'write only' because in my book that is part of the access level -
public read - protected write? ). The key element here is that if var is
a 'read_only' DateTime we don't need all the crap of DateTimeImmutable
and Derick's attempt at adding 'mutability' to the original dateTime
class would probably not have existed? The key I think here is IF 'var'
has been initialized and that depends on - perhaps - if the type
not_null is true. const comes to mind here as well and a
const var DateTime $start; Would give you a fixed snapshot time

HOPEFULLY you already see where this is going ...

Attributes such as __type, __limit, __length, __enum apply to the var
and are then used to ensure that the created value is valid.

Just to complete the picture in my archaic working practice...

public var $root_person
  $root_person->__type( Person, not_null = false );
  $root_person->__init( id1 );
Would have a value of an associative array of the data for 'Person'
consisting of the list of fully typed and constrained 'var' items. The
CODE for Person would simply work on the pointer to that hash. Which is
why I think I'm getting mixed up over the difference between the array
view of a value and the object view. In PHP they used to be
interchangeable but now things like this RFC are making them something
different?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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