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 bu
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
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 somewha
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).
Ite
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...
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 `
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 concealin
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 -
>
> 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* f
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 instanc
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
> 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 itsel
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 someth
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.
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 th
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
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 wit
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 o
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 fo
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
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 c
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 obj
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".
> > Tha
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
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 unintialize
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 acceptab
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
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, wheneve
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 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
do
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
liter
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 workin
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, b
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.
> >
> > Pl
> -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
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
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 {
so
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? Wh
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?
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 e
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 Row
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 contai
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.
> >
> > P
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
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 Lis
45 matches
Mail list logo
