Vote: Anonymous Classes

11 years ago by Joe Watkins — view source

unread

Morning Chaps,

I have opened the vote on anonymous classes, following on from

conversations had in IRC, we have the option to postpone this until 5.7 ...

Cheers

11 years ago by Pierre Joye — view source

unread

hi!

Morning Chaps,
    I have opened the vote on anonymous classes, following on from
conversations had in IRC, we have the option to postpone this until 5.7 ...

Can you move it to the voting phase section please?

--
Pierre

@pierrejoye | http://www.libgd.org

11 years ago by Pierre Joye — view source

unread

hi,

Morning Chaps,
    I have opened the vote on anonymous classes, following on from
conversations had in IRC, we have the option to postpone this until 5.7 ...

Also I do not always follow IRC discussions. What is the reasoning
behind post pone this feature to an hypothetical 5.7? Or why not 5.6?

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

11 years ago by Joe Watkins — view source

unread

hi,
Morning Chaps,
     I have opened the vote on anonymous classes, following on from
conversations had in IRC, we have the option to postpone this until 5.7 ...
Also I do not always follow IRC discussions. What is the reasoning
behind post pone this feature to an hypothetical 5.7? Or why not 5.6?

Cheers,

Morning Pierre,

5.6 remains an option ...

I brought it up in IRC the other day and someone, I forget who, but

recognized them at the time, said they'd rather see it in 5.7, then a
few people joined in the discussion and I couldn't really argue with
their reasoning.

The main point was that even a simple patch can have a destabilizing

effect, and we've already merged several "simple" patches into 5.6.

I think it's a bit early to call time on 5.6 features, and I think

features like this require quite some time for adoption and should be
out as quickly as possible ...

I don't really know what is best ...

Moved to voting bit ..

Sorry mike, thanks for posting link :)

Cheers

11 years ago by Pierre Joye — view source

unread

    5.6 remains an option ...

    I brought it up in IRC the other day and someone, I forget who, but
recognized them at the time, said they'd rather see it in 5.7, then a few
people joined in the discussion and I couldn't really argue with their
reasoning.
    The main point was that even a simple patch can have a destabilizing
effect, and we've already merged several "simple" patches into 5.6.
    I think it's a bit early to call time on 5.6 features,

It is not and we should begin soon to branch 5.6 and go with the
milestones planing to get it out in June.

and I think
features like this require quite some time for adoption and should be out as
quickly as possible ...

I agree.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

11 years ago by Joe Watkins — view source

unread

     5.6 remains an option ...

     I brought it up in IRC the other day and someone, I forget who, but
recognized them at the time, said they'd rather see it in 5.7, then a few
people joined in the discussion and I couldn't really argue with their
reasoning.
     The main point was that even a simple patch can have a destabilizing
effect, and we've already merged several "simple" patches into 5.6.
     I think it's a bit early to call time on 5.6 features,
It is not and we should begin soon to branch 5.6 and go with the
milestones planing to get it out in June.

and I think
features like this require quite some time for adoption and should be out as
quickly as possible ...

I agree.

Cheers,

Hi Pierre,

Re: "It is not ..."

You seem to agree :)

If we should do it soon, and not now, then it is a bit too early
isn't it ??

The end of 2015 is very far away from the perspective of the PHP user;
they are not engaged in learning what will be available in two years
time, look at adoption rates. The anonymous classes patch is actually
simple, I can't imagine that it will have a profound effect on the
things around it ...

Cheers
Joe

11 years ago by johannes@schlueters.de — view source

unread

I brought it up in IRC the other day and someone, I forget who, but
recognized them at the time, said they'd rather see it in 5.7, then a
few people joined in the discussion and I couldn't really argue with
their reasoning.

When I brought this up I was on my current primary rant. Even small
additions to the language have an impact on tools, best practices, ...
which have to be explored about how to use them and how those interact
with each other.

To be clear: I love anonymous classes, I always wanted them when using
FilterIterator etc. (while meanwhile generators+closures might be a
better tool for some of those use cases) But we are moving extremely
fast in reshaping the language making it hard for our users, of which
many -- in my assumption -- primarily want a stable platform, to keep
up.

Oh and talking about "stable platform". Current bug count: 3891

See also my previous message on that subject:
http://news.php.net/php.internals/69093

johannes

11 years ago by Pierre Joye — view source

unread

On Mon, Oct 7, 2013 at 1:49 PM, Johannes Schlüter
johannes@schlueters.de wrote:

Oh and talking about "stable platform". Current bug count: 3891

And most of them are not in the language per se but in extensions or
some totally ignored (see #65486 for what where you are in charge :).

Now, ranting on IRC is all good and shiny. Leading new RFC
contributors to confusion and mess up a vote is something slightly
less shiny. If you could raise your actual points on the list next
time, during the discussion period, then we will not lose time trying
to figure out what happened or what led him to propose such choices.
Thanks.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

11 years ago by Joe Watkins — view source

unread

I brought it up in IRC the other day and someone, I forget who, but
recognized them at the time, said they'd rather see it in 5.7, then a
few people joined in the discussion and I couldn't really argue with
their reasoning.

When I brought this up I was on my current primary rant. Even small
additions to the language have an impact on tools, best practices, ...
which have to be explored about how to use them and how those interact
with each other.

To be clear: I love anonymous classes, I always wanted them when using
FilterIterator etc. (while meanwhile generators+closures might be a
better tool for some of those use cases) But we are moving extremely
fast in reshaping the language making it hard for our users, of which
many -- in my assumption -- primarily want a stable platform, to keep
up.

Oh and talking about "stable platform". Current bug count: 3891

See also my previous message on that subject:
http://news.php.net/php.internals/69093

johannes

The observation that even a small patch has an impact, or can have an
impact is valid. But then to talk about adoption time turns your
reasoning a bit circular: adoption does take time, if we want for
adoption to take place then the earlier a patch gets merged the better,
regardless of the complexity of the patch.

I did see your "rant", though it's not really a rant; perfectly valid
observations. Still, I don't know what you hope to achieve by pointing
out the differences between the development of C or Java, and PHP:
progress plotted on a graph nobody would expect to see any kind of
relationship or commonality between these languages. So while they are
valid observations they aren't really relevant.

The bug count is a bit shameful, some effort should obviously be spent
on bugs ...

Cheers
Joe

11 years ago by johannes@schlueters.de — view source

unread

The observation that even a small patch has an impact, or can have an
impact is valid. But then to talk about adoption time turns your
reasoning a bit circular: adoption does take time, if we want for
adoption to take place then the earlier a patch gets merged the better,
regardless of the complexity of the patch.

The issue is not that we are adding a single patch the issue is that we
recently change the language in a rapid pace.

I did see your "rant", though it's not really a rant; perfectly valid
observations. Still, I don't know what you hope to achieve by pointing
out the differences between the development of C or Java, and PHP:
progress plotted on a graph nobody would expect to see any kind of
relationship or commonality between these languages. So while they are
valid observations they aren't really relevant.

It is the only metric I have to answer comments if the sort "oh, PHP is
developing so slowly" while we are fast in changing the language.

What we i.e. don't do is trying to adopt our "standard library" to new
paradigms being introduced. Also after changing the language we don't
really check how this impacts new languages features. Maybe generators
have an impact on the way anonymous classes should be designed? etc. I
guess most here look at this with a PHP 5.2/5.3 mindset, not 5.5 or at
least 5.4.

that all said:

The bug count is a bit shameful, some effort should obviously be spent
on bugs ...

This is the actual point here: We as a community at large should imo
focus more on fixing bugs instead of creating new ones. If we could
spend more of the time we spend on discussing new things on actually
fixing bugs instead it is my unproven subjective claim that we'd make
more people happy than by any "syntax sugar".

And again to be really clear: This is nothing directly related to this
feature, this patch or even you, but a very general opinion/observation
from my side based on my observations and my discussions with users
about current state of things.

With that: All from my side is said and I hope we can end this more
general sub-thread and use the time better :-)

johannes

11 years ago by Pierre Joye — view source

unread

On Mon, Oct 7, 2013 at 5:30 PM, Johannes Schlüter
johannes@schlueters.de wrote:

The observation that even a small patch has an impact, or can have an
impact is valid. But then to talk about adoption time turns your
reasoning a bit circular: adoption does take time, if we want for
adoption to take place then the earlier a patch gets merged the better,
regardless of the complexity of the patch.

The issue is not that we are adding a single patch the issue is that we
recently change the language in a rapid pace.

I did see your "rant", though it's not really a rant; perfectly valid
observations. Still, I don't know what you hope to achieve by pointing
out the differences between the development of C or Java, and PHP:
progress plotted on a graph nobody would expect to see any kind of
relationship or commonality between these languages. So while they are
valid observations they aren't really relevant.

It is the only metric I have to answer comments if the sort "oh, PHP is
developing so slowly" while we are fast in changing the language.

We do not change the language. We improve it. Changing the language
implies that one has to change his existing code or application to get
them run on a new release. That's not the case between 5.4 and 5.5,
and should not be between 5.5 and 5.6.

However we are not fast or slow, we only fill gaps with other modern languages.

What we i.e. don't do is trying to adopt our "standard library" to new
paradigms being introduced. Also after changing the language we don't
really check how this impacts new languages features. Maybe generators
have an impact on the way anonymous classes should be designed? etc. I
guess most here look at this with a PHP 5.2/5.3 mindset, not 5.5 or at
least 5.4.

That's a good point and that's why we have RFCs. We have to review the
impacts of a new feature, discuss the possible issues (design, BC,
etc.).

that all said:

The bug count is a bit shameful, some effort should obviously be spent
on bugs ...

This is the actual point here: We as a community at large should imo
focus more on fixing bugs instead of creating new ones.

A project focusing only on fixing bugs and does not implement new
features is a dead project, they only don't know it yet.

If we could
spend more of the time we spend on discussing new things on actually
fixing bugs instead it is my unproven subjective claim that we'd make
more people happy than by any "syntax sugar".

I think it is somehow not correct to say that.

My team participates in a lot of discussions, we test all RFCs, before
they end in the voting phase, continuously. We fix bugs, tons of bugs.
We report bugs too. And many other developers do so as well. On the
other hand some developers discuss/argue a lot while not fixing bugs
at all nor developing new features. There are also developers being
better at developing new features rather than doing QA. That's all
good and we should try to figure out a way to work better together
instead of blocking each other.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

11 years ago by Michael Wallner — view source

unread

Morning Chaps,
    I have opened the vote on anonymous classes, following on from
conversations had in IRC, we have the option to postpone this until 5.7 ...

You could have done us laziers a favor and add the link:
https://wiki.php.net/rfc/anonymous_classes#voting :)

--
Regards,
Mike

11 years ago by Nikita Popov — view source

unread

Morning Chaps,
    I have opened the vote on anonymous classes, following on from
conversations had in IRC, we have the option to postpone this until 5.7 ...

Cheers

The "Include in PHP 5.7" voting option, does this mean that we already now
decide to include it in 5.7 or does it mean that we wish to reevaluate the
feature during the 5.7 cycle?

Nikita

11 years ago by Joe Watkins — view source

unread

Morning Chaps,
     I have opened the vote on anonymous classes, following on from
conversations had in IRC, we have the option to postpone this until 5.7 ...

Cheers
The "Include in PHP 5.7" voting option, does this mean that we already now
decide to include it in 5.7 or does it mean that we wish to reevaluate the
feature during the 5.7 cycle?

Nikita

I'm not sure, whatever seems appropriate ... if we're going to say that
it's too late for this to go in 5.6, then it can't be too early to
decide it can go in 5.7 can it ??

Cheers
Joe

11 years ago by Joe Watkins — view source

unread

Morning Chaps,
     I have opened the vote on anonymous classes, following on from
conversations had in IRC, we have the option to postpone this until
5.7 ...

Cheers
The "Include in PHP 5.7" voting option, does this mean that we already
now
decide to include it in 5.7 or does it mean that we wish to reevaluate
the
feature during the 5.7 cycle?

Nikita
I'm not sure, whatever seems appropriate ... if we're going to say that
it's too late for this to go in 5.6, then it can't be too early to
decide it can go in 5.7 can it ??

Cheers
Joe
Morning Chaps,

On the advice of many, I have restarted the vote, sorry for the

inconvenience/confusion ...

Cheers
Joe

11 years ago by Peter Cowburn — view source

unread

Morning Chaps,
    On the advice of many, I have restarted the vote, sorry for the
inconvenience/confusion ...

https://wiki.php.net/rfc/anonymous_classes#voting (re-link, for the lazy)

The voting options changed from choosing a version ("5.6", "5.7") or
rejecting… too a much simpler, yes/no for sticking this into master. Which
branch/release the feature makes it into is something to be decided down
the line (ultimately, by the RMs).

Cheers
Joe

11 years ago by Sebastian Bergmann — view source

unread

I have opened the vote on anonymous classes, following on from
conversations had in IRC, we have the option to postpone this until 5.7

The option to postpone for PHP 5.7 implies that there is already a
deadline for PHP 5.6. Is there?

11 years ago by Pierre Joye — view source

unread

I have opened the vote on anonymous classes, following on from
conversations had in IRC, we have the option to postpone this until 5.7

The option to postpone for PHP 5.7 implies that there is already a
deadline for PHP 5.6. Is there?

There is a deadline for the next release yes, ~June 2014.

Cheers,

Pierre

@pierrejoye | | http://www.libgd.org

11 years ago by Paul Dragoonis — view source

unread

Hi Joe,

Thanks for your hard work on anonymous classes.

I voted no because I feel it's just adding more and more ways to achieve
similar results and the syntax is just more sugary fluff to allow people to
do things the wrong way.

We've had a lot of new features in recent versions, i.e: traits, so I
believe this isn't something PHP needs right now and PHP needs to focus on
bug fixing and solidifying what we have right now.

Thanks,
Paul

Morning Chaps,
     On the advice of many, I have restarted the vote, sorry for the
inconvenience/confusion ...
https://wiki.php.net/rfc/**anonymous_classes#voting https://wiki.php.net/rfc/anonymous_classes#voting(re-link, for the lazy)

The voting options changed from choosing a version ("5.6", "5.7") or
rejecting… too a much simpler, yes/no for sticking this into master.
Which
branch/release the feature makes it into is something to be decided down
the line (ultimately, by the RMs).

Cheers
Joe

Morning All,
    To anyone who has voted or will vote no; if you have voted no but
is something that could be done to the patch to change your mind, please do
speak up :)
    If you voted/will vote no and there's nothing that can change your
mind, I'd still be interested in hearing the reasoning ...
    This is a pretty quiet vote ... as this is the first RFC I have
put forward, I'd like a bit more feedback so I can avoid the avoidable in
the future ...

Cheers
Joe

11 years ago by Ferenc Kovacs — view source

unread

Morning Chaps,
     On the advice of many, I have restarted the vote, sorry for the
inconvenience/confusion ...
https://wiki.php.net/rfc/**anonymous_classes#voting https://wiki.php.net/rfc/anonymous_classes#voting(re-link, for the lazy)

The voting options changed from choosing a version ("5.6", "5.7") or
rejecting… too a much simpler, yes/no for sticking this into master.
Which
branch/release the feature makes it into is something to be decided down
the line (ultimately, by the RMs).

Cheers
Joe

Morning All,
    To anyone who has voted or will vote no; if you have voted no but
is something that could be done to the patch to change your mind, please do
speak up :)
    If you voted/will vote no and there's nothing that can change your
mind, I'd still be interested in hearing the reasoning ...
    This is a pretty quiet vote ... as this is the first RFC I have
put forward, I'd like a bit more feedback so I can avoid the avoidable in
the future ...

Cheers
Joe

--

I have voted no based on the lack of support for
serialization/unserialization, and I think that we agreed that without
somehow naming the class, we can't support that, and having a name would
defeat the purpose of this feature.

I'm looking forward to nested classes though.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

11 years ago by Joe Watkins — view source

unread

Morning Chaps,
      On the advice of many, I have restarted the vote, sorry for the
inconvenience/confusion ...
https://wiki.php.net/rfc/**anonymous_classes#voting https://wiki.php.net/rfc/anonymous_classes#voting(re-link, for the lazy)

The voting options changed from choosing a version ("5.6", "5.7") or
rejecting… too a much simpler, yes/no for sticking this into master.
Which
branch/release the feature makes it into is something to be decided down
the line (ultimately, by the RMs).

Cheers
Joe

Morning All,
     To anyone who has voted or will vote no; if you have voted no but
is something that could be done to the patch to change your mind, please do
speak up :)
     If you voted/will vote no and there's nothing that can change your
mind, I'd still be interested in hearing the reasoning ...
     This is a pretty quiet vote ... as this is the first RFC I have
put forward, I'd like a bit more feedback so I can avoid the avoidable in
the future ...

Cheers
Joe

--
I have voted no based on the lack of support for
serialization/unserialization, and I think that we agreed that without
somehow naming the class, we can't support that, and having a name would
defeat the purpose of this feature.

I'm looking forward to nested classes though.

Tyrael,

As mentioned in the RFC, there's nothing stopping you from serializing

an anonymous class.
Anonymous classes are named, they have to be; they are named after
the codepath (so file/function/class) prefixed with namespace where they
are used ... so in fact there's nothing wrong with the vast majority of
applications using serialization of anonymous class objects.

Nested classes is more complicated than anonymous ones, if this doesn't

get in on a vote I don't see nested classes getting in either; if the
reason people are voting no is really that "we need to concentrate on
bugs", then what is really the point in preparing another RFC before 5.6
is out in the wild ...

I hear the syntax sugar thing ... but it's starting to wear a bin thin,

it's a phrase thrown around without much justification or thought:
Almost everything you add at the Zend level which requires some kind of
syntax (so, pretty much everything) can be described as syntactic sugar.
It is only a parser modification, but that should only make it more
appealing, we aren't asking anything new of Zend ...

In any case, I appreciate the input :)

Cheers
Joe

11 years ago by Ferenc Kovacs — view source

unread

> I have voted no based on the lack of support for
>> serialization/unserialization, and I think that we agreed that without
>> somehow naming the class, we can't support that, and having a name would
>> defeat the purpose of this feature.
>>
>> I'm looking forward to nested classes though.
>>
>> Tyrael,
>
> As mentioned in the RFC, there's nothing stopping you from
> serializing an anonymous class.
> Anonymous classes are named, they _have_ to be; they are named
> after the codepath (so file/function/class) prefixed with namespace where
> they are used ... so in fact there's nothing wrong with the vast majority
> of applications using serialization of anonymous class objects.
>

yeah, and you can't autoload that, and if you move the instanitation of an
anonymous class the generated internal classname will be different.
and that is all fine for handling the instance in that specific request,
but makes any attempt to persist and restore really fragile.
I also think that anonymous classes and functions should be similar in this
sense, and currently we don't allow the serialization of Closure
instances(but we do allow the serialization of `create_function()`, and I do
understand why is that, but it is not what most people would guess), which
is a bit sucky, because you have to remember, that closures work the same
way as any other callable, except that it can't be serialized (but it can
be json_encoded and it will result in an empty object).
I think that having such restrictions, when something almost works the way
one would expect is wrong.

>
> Nested classes is more complicated than anonymous ones, if this
> doesn't get in on a vote I don't see nested classes getting in either; if
> the reason people are voting no is really that "we need to concentrate on
> bugs", then what is really the point in preparing another RFC before 5.6 is
> out in the wild ...
>

anonymous classes and nested classes have a bit different usecases, hence
supporter base, I think you shouldn't guess on the result for that based on
the feedback on anonymous classes.

>
> I hear the syntax sugar thing ... but it's starting to wear a bin
> thin, it's a phrase thrown around without much justification or thought:
> Almost everything you add at the Zend level which requires some kind of
> syntax (so, pretty much everything) can be described as syntactic sugar. It
> is only a parser modification, but that should only make it more appealing,
> we aren't asking anything new of Zend ...
>

I didn't bring up this point, but I do agree that having changes in the
ZE/parser should be done with a good reason, and simply because it could
have a much wider impact area and less people familiar with fixing those
kind of bugs.

>
> In any case, I appreciate the input :)
>

and we appreciate your work on improving php. _o_

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

11 years ago by Joe Watkins — view source

unread

Just quick note ... If you autoload a class which in turn unserializes an
object of an anonymous class autoloading will not be invoked for the
anonymous class ... It is compiled when you load the super / outer class
... Am out and about on phone ... I think these kinds of issues can be
explained / resolved ...

>
> I have voted no based on the lack of support for
>>> serialization/unserialization, and I think that we agreed that without
>>> somehow naming the class, we can't support that, and having a name would
>>> defeat the purpose of this feature.
>>>
>>> I'm looking forward to nested classes though.
>>>
>>> Tyrael,
>>
>> As mentioned in the RFC, there's nothing stopping you from
>> serializing an anonymous class.
>> Anonymous classes are named, they _have_ to be; they are named
>> after the codepath (so file/function/class) prefixed with namespace where
>> they are used ... so in fact there's nothing wrong with the vast majority
>> of applications using serialization of anonymous class objects.
>>
>
> yeah, and you can't autoload that, and if you move the instanitation of an
> anonymous class the generated internal classname will be different.
> and that is all fine for handling the instance in that specific request,
> but makes any attempt to persist and restore really fragile.
> I also think that anonymous classes and functions should be similar in
> this sense, and currently we don't allow the serialization of Closure
> instances(but we do allow the serialization of `create_function()`, and I do
> understand why is that, but it is not what most people would guess), which
> is a bit sucky, because you have to remember, that closures work the same
> way as any other callable, except that it can't be serialized (but it can
> be json_encoded and it will result in an empty object).
> I think that having such restrictions, when something almost works the way
> one would expect is wrong.
>
>
>>
>> Nested classes is more complicated than anonymous ones, if this
>> doesn't get in on a vote I don't see nested classes getting in either; if
>> the reason people are voting no is really that "we need to concentrate on
>> bugs", then what is really the point in preparing another RFC before 5.6 is
>> out in the wild ...
>>
>
> anonymous classes and nested classes have a bit different usecases, hence
> supporter base, I think you shouldn't guess on the result for that based on
> the feedback on anonymous classes.
>
>
>>
>> I hear the syntax sugar thing ... but it's starting to wear a bin
>> thin, it's a phrase thrown around without much justification or thought:
>> Almost everything you add at the Zend level which requires some kind of
>> syntax (so, pretty much everything) can be described as syntactic sugar. It
>> is only a parser modification, but that should only make it more appealing,
>> we aren't asking anything new of Zend ...
>>
>
> I didn't bring up this point, but I do agree that having changes in the
> ZE/parser should be done with a good reason, and simply because it could
> have a much wider impact area and less people familiar with fixing those
> kind of bugs.
>
>
>>
>> In any case, I appreciate the input :)
>>
>
> and we appreciate your work on improving php. _o_
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu

11 years ago by Matthew Leverton — view source

unread

    This is a pretty quiet vote ... as this is the first RFC I have put
forward, I'd like a bit more feedback so I can avoid the avoidable in the
future ...

I'm not a voter, but I'd lean toward 'no' on this because a) I really
dislike the syntax and b) it didn't seem to play 100% nicely with core
PHP features (e.g. serialization). However, I do think there's a place
for such a feature in PHP though (just take a look at SplHeap).

I wish RFC voters had to leave a brief comment (even if from a canned
list) on the voting page when voting 'no' because it would add a lot
more transparency to the process. I know a lot of people do comment
somewhere and I trust that they vote responsibly, but it's hard to put
it all together at the end.

--
Matthew Leverton

11 years ago by David Soria Parra — view source

unread

Matthew Leverton leverton@gmail.com schrieb:

I wish RFC voters had to leave a brief comment (even if from a canned
list) on the voting page when voting 'no' because it would add a lot
more transparency to the process. I know a lot of people do comment
somewhere and I trust that they vote responsibly, but it's hard to put
it all together at the end.

It's a wiki page, all voters have edit rights. We can simply introduce a
"vote reasoning" part.