Oh man I am so happy to know that, was expecting nested or anonymous class for a while now, and the latter looks totally possible for PHP 5.6. Whats real amazing is that it was just proposed on Sep 22th, and now its already 'under discussion' rather than 'in draft'. Here is one example as given from the rfc page:

Of course the example above only shows the proposed syntax, the power of anonymous classes will be more evident working with event classes. I actually consider the syntax a little bit verbose, why not use this instead?

simple syntax:

return new MyInterface{
}

vs proposed syntax:

return new class extends MyInterface{
}

But even with this minor verbosity, the anonymous class proposal is really nice and we should all support it to make to PHP 5.6. I'd love to see inner/nested class as well at some point, but Id already be happy if at least anonymous class support is added. I mean, one is better than zero like always?

Also there are other proposed features on PHP RFC that I'd really love to see in PHP 5.6, such as Extended Keyword Support(so that you can create a class called Array rather than attempting to avoid keyword conflict) and Named Parameters(likely a C# port, but its gonna be nice). Looks like Java style variable number argument-list feature is already accepted and will be implemented in PHP 5.6, it looks great and still we need a bigger feature comparable to PHP 5.3's namespace, PHP 5.4's trait and PHP 5.5's generator in PHP 5.6 since it's a major new version. Anonymous class can be this big feature, dont you agree? For me though, this is definitely the most exciting feature to be added to PHP since namespace, I cant wait to see it in action already.

fretburner
—
2013-09-25T10:40:54Z —
#2

I've never come across anonymous classes before. What are they used for and why are they useful? And which other languages have this feature?

lampcms_com
—
2013-09-25T11:16:38Z —
#3

In Java they are pretty common. Usually they are used to implement an interface in-place. Common use of them in the UI design where you need to implement some type of event listener with minimal amount of extra coding, so you write a few lines of code and implement inside of your class as anonymous inner class (a class inside a class). I am not sure if php will allow inner classes.

cpradio
—
2013-09-25T11:16:40Z —
#4

Hall_of_Famer said:

simple syntax:

`php

return new MyInterface{

}

`

vs proposed syntax:

`php

return new class extends MyInterface{

}

`

I'm not sure I agree with your "simple" syntax. That limits what you can do. With the proposed syntax, it seems to me they are allowing me to extend other classes or implement an interface, or I could just create an anonymous class that has no tie to an existing class/interface. It would also seem appropriate, that it would permit me to implement multiple interfaces, not just one.

So the following becomes an option (which is VERY cool in my opinion)

return new class extends MyBaseClass, MyInterface, MyInterface2 {
}

How would you do that with the simplified syntax? Not to mention, writing new MyInterface is just awkward. Interfaces are not classes, they can't be constructed that way, they have to be implemented (personal opinion).

@fretburner ; This [result was a good read, I thought it summed it up well. [url=http://msdn.microsoft.com/en-us/library/vstudio/bb397696.aspx]C#](http://stackoverflow.com/questions/487126/is-usage-of-anonymous-classes-in-java-considered-bad-style-or-good) and Java both have this.

In C# specifically, it comes into great use when using LINQ to SQL. You can return a new object containing the columns from your table on the fly and then iterate through them without the need to create an actual class. Most cases (all cases?) anonymous classes are to be short lived. Meaning you don't see value of a physical class in your project because it will only be used in this particular scenario; once you exceed that, you should consider creating a physical class (my opinion).

TomB
—
2013-09-25T13:22:21Z —
#5

Very interesting concept. I'm struggling to think of any practical applications where this is useful though... other than saving a couple of lines of code (if that!) what advantage is there over formally defined classes?

It does strike me as an odd thing to desire from an OOP perspective as arbitrarily constructing objects throughout the code is a bad idea and I can't think of a single use for this that wouldn't involve exactly that. From a TDD perspective this sounds like a rather large headache.

Hall_of_Famer
—
2013-09-25T16:29:34Z —
#6

cpradio said:

I'm not sure I agree with your "simple" syntax. That limits what you can do. With the proposed syntax, it seems to me they are allowing me to extend other classes or implement an interface, or I could just create an anonymous class that has no tie to an existing class/interface. It would also seem appropriate, that it would permit me to implement multiple interfaces, not just one.

So the following becomes an option (which is VERY cool in my opinion)

`phpreturn new class extends MyBaseClass, MyInterface, MyInterface2 {

}`

How would you do that with the simplified syntax? Not to mention, writing new MyInterface is just awkward. Interfaces are not classes, they can't be constructed that way, they have to be implemented (personal opinion).

Well its actually simple enough, below are two possible proposals:

return new MyBaseClass, MyInterface, MyInterface2{
};

Or:

return new (MyBaseClass, MyInterface, MyInterface2{
};

There is little ambiguity with the simpler syntax, they may feel more like java or C# but apparently there's a reason why anonymous classes are designed this way in these two languages. I don't see how awkward it is to use the syntax new Interface since that's exactly how java's anonymous class works and no one complains. I know PHP is not java, it's nice to invent new syntax unique and natural to PHP, but inventions are only innovations when their advantages outweigh disadvantages.

cpradio
—
2013-09-25T17:45:32Z —
#7

@Hall_of_Famer ; That's fair enough. I think they may be trying to reuse existing logic in their parser, which already supports finding class ... extends ... (just a guess)

Ah, think about it. With your approach, it would create a new instance of MyBaseClass instead of an anonymous class that extends MyBaseClass (without parser changes).

Hall_of_Famer
—
2013-09-25T18:27:28Z —
#8

Yes that's a possibility, I'd say its a bit more difficult to implement the shorthand syntax I suggested, but it seems that the developer said he has tried and it worked. He didn't like it cause it feels more java, but I disagree since after all java does not hold copyrights of this anonymous class syntax anyway. I can say the same thing on PHP's anonymous/ lambda functions look like javascript, and nobody seems to have a problem with that.

I'd personally be more interested in performance difference, if there is a clear justification that the simpler syntax is more expensive on performance I'd completely drop my suggestion. Yeah, it's meant to be a suggestion not an argument, as even with the more verbose syntax I'd rather have this feature than not. The verbosity of syntax is a small price to pay for a big feature to be implemented, don't you think so?

cpradio
—
2013-09-25T18:35:27Z —
#9

Hall_of_Famer said:

Yes that's a possibility, I'd say its a bit more difficult to implement the shorthand syntax I suggested, but it seems that the developer said he has tried and it worked. He didn't like it cause it feels more java, but I disagree since after all java does not hold copyrights of this anonymous class syntax anyway. I can say the same thing on PHP's anonymous/ lambda functions look like javascript, and nobody seems to have a problem with that.

I'd personally be more interested in performance difference, if there is a clear justification that the simpler syntax is more expensive on performance I'd completely drop my suggestion. Yeah, it's meant to be a suggestion not an argument, as even with the more verbose syntax I'd rather have this feature than not. The verbosity of syntax is a small price to pay for a big feature to be implemented, don't you think so?

Yes, I agree with that. And I think you have a valid argument. I just see the readability of it to be confused with new MyBaseClass(); versus new MyBaseClass { }; produce two different results to be really hard to detect just by reading it.

Michael_Morris1
—
2013-09-26T14:46:56Z —
#10

Things we need: UTF EncodingThings we get: Anonymous classes

:sigh: PHP.

Hall_of_Famer
—
2013-09-26T15:05:08Z —
#11

Michael_Morris said:

Things we need: UTF EncodingThings we get: Anonymous classes

:sigh: PHP.

As far as I know, anonymous class has not made it to voting phase yet... It has just been recently proposed, that's it.

Michael_Morris1
—
2013-09-26T15:13:59Z —
#12

It will. It has all the markings of "Look, shiny" that appeals to the dev team, while the grunt work changes the language needs to have done get neglected. Proper UTF-8 handling being chief among them.

Hall_of_Famer
—
2013-09-26T16:19:29Z —
#13

Michael_Morris said:

It will. It has all the markings of "Look, shiny" that appeals to the dev team, while the grunt work changes the language needs to have done get neglected. Proper UTF-8 handling being chief among them.

I'm not quite sure tbh, can't find a pattern that describes what features are more likely to be added to PHP than the others. I wonder why goto makes it to PHP, it's one of the worst programming practices for coders of any experience level.

pbyrne84
—
2013-09-26T17:46:09Z —
#14

Andrei Zmievski did a slideshare of what went wrong with UTF-8 and PHP

It seems to be more than grunt work is needed as it was tried but it effectively failed for a few reasons. Being hit with sticks may be far more pleasurable than trying to get that working across everything without major BC breaks.

This anonymous class thing is one guy doing a patch which would of probably got a lot more negative conversation prior to Anthony Ferrera leaving the internals. The voting counts on many things such as BC break, maintenance overhead, implementation, fits the "nature of PHP" etc. It will likely need a 66% vote like the failed properties vote.

Hall_of_Famer
—
2013-09-26T18:02:31Z —
#15

umm what happened to Anthony Ferrera? Why did he leave PHP internals? I wonder what it means to 'fits the nature of PHP', does PHP have a nature?

Anyway it is interesting to see if an RFC actually reaches exactly 2/3 of the votes and barely passes the requirement, property accessors still dont come that close to cause a serious controversy.

Stomme_poes
—
2013-09-27T10:35:50Z —
#16

I wonder what it means to 'fits the nature of PHP', does PHP have a nature?

I'm not sure if PHP has one, though I suspect it does, but many languages have a "feel" to them, or a more-socially-accepted-way-of-doing-things, determined by the community. In Python, it's called "Pythonic", and means little more than "yeah that other way works but it doesn't respect our Zen Of Python guidelines we strive to live by". An example would involve the difference between using some well-loved and built-in functionality to help implement some new idea, as opposed to cobbling the new idea from many other areas and not using stuff someone bothered to optimise the compiler for, or cobbled together in a way that doesn't match the readability style of similar ideas. That kind of thing.

The opposite would regard the saying "You can write FORTRAN in any language".

pbyrne84
—
2013-09-27T19:11:04Z —
#17

'fits the nature of PHP' is one of those things that caused a lot of arguments in prior RFCs. Basically Stomme poes is right but in PHP land the 'way' is largely a figment. For example Wordpress plugin development is probably very different from large scale/long life time development so even seeing things "as a way" is likely to be problematic as different approaches have different benefits and change can benefit one and be detrimental to the other. For example upgrading to PHP5.4 and running E_ALL can be problematic as strict is now included and it can it can break a lot of legacy code if E_ALL is deemed important and that upsets at least one person heavily, the code can be easily rectified if it has good unit test/integration test coverage but the development has to live in a world where having good automated tests is important. Sometimes the PHP way is chuck it out cheap and quick and then throw it at a server. Other times the cost of keeping it has to be taken heavily into account so that approach is just not feasible. I personally don't believe there is a way, but some people are quite attached to what they view PHPs identity is (sometimes that identity is simply "Its not Java").

I know a developer who describes a group of developers as an "argument of developers" and it is pretty much the case in internals as new functionality often has to be forged in quite a violent process. Possibly spend months doing patches, rfc's and being constantly active in what seems to be quite stressful discussions and then get a no vote at the end with no clear reason.

The strongest voices on internals who would usually be against something like anonymous classes( who are also the ones more likely to implement the UTF-8 stuff) are staying pretty quite in this discussion so far so it will be interesting to see how it turns out.

Lemon_Juice
—
2013-09-27T19:53:17Z —
#18

Michael_Morris said:

It will. It has all the markings of "Look, shiny" that appeals to the dev team, while the grunt work changes the language needs to have done get neglected. Proper UTF-8 handling being chief among them.

I disagree as to UTF-8 - this is bound to make PHP overall slower while providing not enough benefit to be worth it. The sites I code are all UTF-8 and most often in languages that have non-English letters and I don't feel the need for native UTF-8 support at all. We have mb functions, we have the regex 'u' modifier - that's enough to cover all my needs, and still I find using them pretty rarely. Just improving the existing mb library is the best direction IMHO.

However, I agree that anonymous classes are nothing really important. I'd rather see a complete and fully usable namespace support without the present quirks.

TomB
—
2013-09-27T21:08:17Z —
#19

Lemon_Juice said:

I disagree as to UTF-8 - this is bound to make PHP overall slower while providing not enough benefit to be worth it. The sites I code are all UTF-8 and most often in languages that have non-English letters and I don't feel the need for native UTF-8 support at all. We have mb functions, we have the regex 'u' modifier - that's enough to cover all my needs, and still I find using them pretty rarely. Just improving the existing mb library is the best direction IMHO.

However, I agree that anonymous classes are nothing really important. I'd rather see a complete and fully usable namespace support without the present quirks.

Just because you don't use features often doesn't make them pointless. A lot of the sites I work on daily are multi-lingual. Yes, you can make it work.. but it presents yet another hurdle for developers. It's something that causes annoying bugs and constantly having to be "on guard" while developing.

I haven't looked into it and there's probably a reason but why can't the PHP developers add unicode support and just make it off by default (for now) and available in php.ini? That avoids backwards compatibility issues because it only gets enabled by people who have explicitly decided to use it.

That said, I agree with your opinion on namespaces. One of the biggest missing features is being able to load legacy code into an explicit namespace e.g. require_once 'someclass.php', 'My\Legacy\Code\Namespace';

Lemon_Juice
—
2013-09-27T21:48:33Z —
#20

TomB said:

Just because you don't use features often doesn't make them pointless. A lot of the sites I work on daily are multi-lingual. Yes, you can make it work.. but it presents yet another hurdle for developers. It's something that causes annoying bugs and constantly having to be "on guard" while developing.

I haven't looked into it and there's probably a reason but why can't the PHP developers add unicode support and just make it off by default (for now) and available in php.ini? That avoids backwards compatibility issues because it only gets enabled by people who have explicitly decided to use it.

I didn't mean this was pointless but it would have a serious (in my opinion) drawback of making PHP slower. Having an option for on/off in php.ini also doesn't cut it because then I either choose to slow down all of my site or not use unicode at all. The use cases I find most often in are ~95% ascii and ~5% unicode - then it's logical I want to use unicode only in those 5% without slowing down the rest. If there was a way to easily choose on run-time whether I want to use unicode or not for each statement/function/method/etc. then I'm all for it (for instance something à la MySQL's COLLATE keyword).