Re: [PHP-DEV] [RFC] Anonymous Classes
Hi Phil.
I really like this feature and am keen to see it go in. Developers
often create classes (which are typically new files) just to extend and
implement a small method. This feature could see codebases become much
lighter. So a massive thanks for your and Joe’s efforts on this.
I have two quite small points I want to make.
Firstly,
When a error occurs on an anonymous class the class description isn’t very
useful (see http://3v4l.org/9Nbea/rfc#tabs). Instead of
“class@0x7f9e33870fd0” Is it possible it could be prefixed with “anonymous”
or something a bit clearer. Further to this if the anonymous class extends
anything it omits the parent class name in the error message (see
http://3v4l.org/UFEbo/rfc#tabs). Is this expected? Could it be something
more helpful?
Secondly, I think we need to either allow the behaviour or generate an
error (similar to anonymous closures) when an anonymous class is
serialized. Please observe the following behaviour..
$foo = new class {
public function Bar () {
echo 'bar';
}
};
// This succeeds. I'd argue an error should be generated at this point
echo $serFoo = serialize($foo);
// Unserialize fails and a notice is generated
$unFoo = unserialize($serFoo);
// Error generated on call
$unFoo-Bar();
see http://3v4l.org/AJY6d/rfc#tabs
That’s all. Again, thanks for your efforts.
/@leedavis81
On Tue, Feb 24, 2015 at 1:52 PM, Philip Sturgeon pjsturg...@gmail.com
wrote:
Good day!
https://wiki.php.net/rfc/anonymous_classes
There's a little RFC + patch that Joe Watkins put together, and as
before with the ArrayOf RFC, I'll be helping out.
So, lets get this discussion rolling.
It was declined for PHP 5 some time ago, and has returned now to try for
PHP 7.
The usage of anonymous classes to some will be instantly offensive,
but really it comes down to the use case. The usage of anonymous
functions compared to declared functions is pretty much the exact same
thing as anonymous classes.
Other than examples on the RFC, Fractal would certainly be happy to
have them: http://fractal.thephpleague.com/transformers/
Defining a class properly is certainly still going to be the majority
of uses of classes in PHP. That helps with the Optimizer, and helps
code reuse.
Sadly due to the way in which people have had ONE CLASS ONE FILE
drilled into their head since PEAR and continuing through Zend and
PSR-0, it can become a PITA to add some simple functionality if a
small class is needed for one tiny thing.
Anonymous functions alleviate that annoyance with a simple and
consistent feature that just give people a nice simple option to get
their jobs done, without hitting autoloaders and file systems to do
it.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Anonymous Classes
Matthew,
On Sun, Mar 8, 2015 at 11:04 PM, Matthew Leverton lever...@gmail.com wrote:
$foo = class extends Callback { ... }
$bar = new $foo;
Nope, none of that. Wrap that in a function or clone it perhaps.
Are you actively against that functionality? (I don't think it's very
useful, but was wondering if you think it's a bad idea for some
reason.)
I'm not sure what people think it should return. The name of the
anonymous class??
e.g., similar to:
class Foo { }
$foo = 'Foo';
$fooInstance = new $foo;
That seems odd to me. It could just return a ReflectionClass object:
$reflector = class { public function bar() { } };
$foo = $reflector-newInstance();
$foo-bar();
But I don't know if that would feel out of place. Otherwise, it seems
like it would need to return some sort of Class object that could be
typecasted, etc ... but in some ways that's what a ReflectionClass
already is.
Just throwing that out there.
Big +1 on the RFC as presented.
--
Matthew Leverton
Thanks for the example! I would say: Yes, I am actively against that stuff.
Firstly, at this time no part of PHP that I know of will smash a
reflection object at you unless you specifically interact with the
reflection API and ask for it. That in itself is a major nope.
Secondly, it am unsure of the uses. you can wrap that in a function or
shove it in a named class if you need to create multiple instances of
it. Or, as I said, there is clone.
If usage of this simple feature starts to show that people feel
constrained by not having this extra feature, then I would say we
should add that later. I am a big fan of keeping it simple and
introducing things as people need them, instead of trying to cover all
future use cases. :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Anonymous Classes
Patrick, On Sat, Mar 7, 2015 at 2:22 AM, Patrick Schaaf p...@bof.de wrote: Am 06.03.2015 20:14 schrieb Philip Sturgeon pjsturg...@gmail.com: Right, this here RFC has been drastically improved. https://wiki.php.net/rfc/anonymous_classes Anyone got any doubts or troubles at this point? Can we / could we do extends self, extends static, or even extends $someclassname ? The first two could be handy in factory like object methods, and the last one generally in factory methods. best regards Patrick Could you maybe make some full examples? I'm not visualising the use case. It sounds like something which would be better off as another RFC as its extra features. This is just making anonymous definitions possible, not trying to take on a whole bunch of different features in one go. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Anonymous Classes
Stanislav,
On Fri, Mar 6, 2015 at 6:42 PM, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
Couple of points to clarify:
1. Is the new syntax new class ... or just class ... and new works
the same? I.e. could you do:
$foo = class extends Callback { ... }
$bar = new $foo;
Nope, none of that. Wrap that in a function or clone it perhaps.
2. What is the scope of the anonymous class? Can it get access to
parent's variable scope? Private functions?
Works the same as any named class. No new special rules here.
Play around on 3v4l and show me an example of something you don't
like, or make sure it works the way you expect.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Anonymous Classes
Just a question, can I do:
$c = class {
public static function square($i) {
return $i*$i;
}
});
echo $c::square(42);
or
$c = class extends DateTime {
public static function createFromFormat($translateFormat, $time) {
$translateFormat = str_replace('foo', 'Y-m-d', $translateFormat);
return parent::createFromFormat($translateFormat, $time);
}
});
$date = $c::createFromFormat('foo', '2015-03-09');
Regards
Thomas
Philip Sturgeon wrote on 06.03.2015 20:14:
Right, this here RFC has been drastically improved.
https://wiki.php.net/rfc/anonymous_classes
Anyone got any doubts or troubles at this point?
It's about 5 days until the vote starts.
--
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] Anonymous Classes
Hi, 2015-03-07 8:28 GMT-03:00 Robert Stoll p...@tutteli.ch: -Ursprüngliche Nachricht- Von: Patrick Schaaf [mailto:p...@bof.de] Gesendet: Samstag, 7. März 2015 08:22 An: Philip Sturgeon Cc: internals; Robert Stoll Betreff: Re: [PHP-DEV] [RFC] Anonymous Classes Am 06.03.2015 20:14 schrieb Philip Sturgeon pjsturg...@gmail.com: Right, this here RFC has been drastically improved. https://wiki.php.net/rfc/anonymous_classes Anyone got any doubts or troubles at this point? Can we / could we do extends self, extends static, or even extends $someclassname ? The first two could be handy in factory like object methods, and the last one generally in factory methods. best regards Patrick Personally, I would go step by step. First introduce anonymous classes and then extend it with features like the one described above - should be less controversial. The last construct idea described by you would introduce dynamic inheritance to a certain degree and I am not so sure if that is really a good idea Cheers, Robert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php That's not controversial, it seems like a basic feature we should have. As anonymous classes is a major feature, adding extends self and extends static at a later stage would only cause portability issues between different versions of PHP7. If we are going to have this, better add it now. +1 Cheers, Márcio
Re: [PHP-DEV] [RFC] Anonymous Classes
2015-03-07 8:22 GMT+01:00 Patrick Schaaf p...@bof.de: Am 06.03.2015 20:14 schrieb Philip Sturgeon pjsturg...@gmail.com: Right, this here RFC has been drastically improved. https://wiki.php.net/rfc/anonymous_classes Anyone got any doubts or troubles at this point? Can we / could we do extends self, extends static, or even extends $someclassname ? +1 Lazare INEPOLOGLOU Ingénieur Logiciel
Re: [PHP-DEV] [RFC] Anonymous Classes
Hi!
Right, this here RFC has been drastically improved.
https://wiki.php.net/rfc/anonymous_classes
Anyone got any doubts or troubles at this point?
It's about 5 days until the vote starts.
Couple of points to clarify:
1. Is the new syntax new class ... or just class ... and new works
the same? I.e. could you do:
$foo = class extends Callback { ... }
$bar = new $foo;
2. What is the scope of the anonymous class? Can it get access to
parent's variable scope? Private functions?
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Anonymous Classes
Hi all,
On Wed, Feb 25, 2015 at 4:06 AM, S.A.N ua.san.a...@gmail.com wrote:
Yes, is problem - properties and methods look the same, how to solve
this problem in PHP I do not know.
Perhaps PHP could interpret this code:
$object =
{
'property' = $value,
'method' = function (){...}
};
AS
$object = new class
{
public $property = $value;
public function method (){...}
}
Use case - inline object without inheritance and traits, only the
properties and methods it brief and easily understood JSON syntax, I
think it would be popular with developers of PHP.
It's not directly related to the topic, but I would like to have code
block that
returns value with this syntax rather than defining anonymous
class/object.
BTW, I'm +1 for the idea having anonymous class.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] [RFC] Anonymous Classes
Right, this here RFC has been drastically improved. https://wiki.php.net/rfc/anonymous_classes Anyone got any doubts or troubles at this point? It's about 5 days until the vote starts. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Anonymous Classes
Am 06.03.2015 20:14 schrieb Philip Sturgeon pjsturg...@gmail.com: Right, this here RFC has been drastically improved. https://wiki.php.net/rfc/anonymous_classes Anyone got any doubts or troubles at this point? Can we / could we do extends self, extends static, or even extends $someclassname ? The first two could be handy in factory like object methods, and the last one generally in factory methods. best regards Patrick
Re: [PHP-DEV] [RFC] Anonymous Classes
On Tue, Mar 3, 2015 at 12:03 PM, Robert Stoll p...@tutteli.ch wrote: Hi Philip -Ursprüngliche Nachricht- Von: Philip Sturgeon [mailto:pjsturg...@gmail.com] Gesendet: Dienstag, 24. Februar 2015 14:52 An: PHP Internals Betreff: [PHP-DEV] [RFC] Anonymous Classes Good day! https://wiki.php.net/rfc/anonymous_classes There's a little RFC + patch that Joe Watkins put together, and as before with the ArrayOf RFC, I'll be helping out. [Robert Stoll] I like the RFC +1 :) Can I also use traits in combination with anonymous classes?=3D20 You can indeed use traits. Should I add this as an example and shove a test in there? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Anonymous Classes
On Tue, Feb 24, 2015 at 2:25 PM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! I like the idea of having anonymous classes, it is very helpful during development to just try something out without having the burden of creating a new file and a complete class including namespace and use declarations, etc. I think this particular argument is a bit backwards. In PHP, you certainly don't need to create new file to just introduce a new class. If you're working within a framework that makes it a problem, time to think if the framework you're using is fit for your purposes. But PHP certainly does not impose such limitations. A great feature of anonymous classes in Java is their ability to access the private/protected properties of the object they are defined in, similar to what Closures do in PHP. The thing is, in Java if you access a variable (without this.), it may be of the current scope, a member of the current class or a member of the class where the anonymous class was defined in. In PHP, you have to use $this- to access class members of That may be a problem to implement, exactly since you need $this in PHP. Second thing is serialization. PHP closures can not be serialized, does the same apply for anonymous classes? It would be really nice if such Serializing is not a problem, unserializing would be - as there may be no class for this object to instantiate. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php If anyone wants to have a play with anonymous classes, our friends over at 3v4l.org have made this incredibly easy to do: http://3v4l.org/elh6I/rfc#rfc-anonymous_classes Awesome. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Anonymous Classes
On Tue, Feb 24, 2015 at 9:58 AM, Florian Anderiasch m...@anderiasch.de wrote: On 02/24/2015 03:29 PM, Dennis Birkholz wrote: Am 24.02.2015 um 14:52 schrieb Philip Sturgeon: https://wiki.php.net/rfc/anonymous_classes I like the idea of having anonymous classes, it is very helpful during development to just try something out without having the burden of creating a new file and a complete class including namespace and use declarations, etc. I don't buy this argument. If your class loader or PSR prevents you from temporarily adding a 2nd bogus class to the same file (not talking about best practices here, obviously) then there's the culprit and it's nothing the language needs to fix. ~Florian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Your reply seems to assume that avoiding rules in a PSR is the only benefit of the RFC, which is weird when there is a whole RFC full of benefits of this RFC. Also, how do you Temporarily add a 2nd bogus class to the same file? Also again, why is it bogus? This RFC allows people to use really simple classes, which implement various things, or provide simple decoration, or insanely easy stubbing, or all sorts of other functionality without having to define it way at the top of the file, or in another file, or whatever. Not just bogus junk, but actual real uses. My mention of PSR (and PEAR and Zend which you didn't mention) was purely a sidenote of This is how the community is doing things which is always relevant to mention, and not a complaint about PSRs. This was common practice for the preceding decade, and again is not the crux of this conversation. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Anonymous Classes
On Tue, Feb 24, 2015 at 9:34 AM, Dmitry Stogov dmi...@zend.com wrote:
On Tue, Feb 24, 2015 at 5:19 PM, Philip Sturgeon pjsturg...@gmail.com
wrote:
On Tue, Feb 24, 2015 at 9:10 AM, Dmitry Stogov dmi...@zend.com wrote:
I think the proposal is a bit incomplete.
It's possible to instantiate an anonymous class, but currently it's not
possible to do with them anything else (assign to variable, pass to
function, etc). Something similar to Closure objects should be
introduced.
Thanks. Dmitry.
1. You can absolutely assign the instantiated classes to variables.
Check out this test in the patch:
https://github.com/krakjoe/php-src/compare/anon#diff-25e330fb5a98810de178a5b798102d01R1
In tests you assign instantiated objects.
$a = new class {...};
$b = new class {...};
I'm talking about classes as first class objects.
$c = class {...};
$a = new $c;
$b = new $c;
2. Why do you say they cannot be passed to a function? I can add a
test if you can give me an example of what you're suggesting doesn't
work.
3. Not sure why we'd need a Closure-alike object. Anonymous classes
are just a class, and classes have all the types and hinting
functionality of regular classes. You don't need to implement a class
to let people know its a class.
Maybe you could expand on that a bit? :)
I tried it in the example above.
Also, classes may be useful without objects at all (just static properties
and methods).
$c = class {...};
$c::static_foo();
Thanks. Dmitry.
Thank you for the example! Your example explains my question 1, but
doesn't seem to explain 2 or 3.
I'll play around with static usage and show it off in the tests.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Anonymous Classes
On 02/24/2015 03:29 PM, Dennis Birkholz wrote: Am 24.02.2015 um 14:52 schrieb Philip Sturgeon: https://wiki.php.net/rfc/anonymous_classes I like the idea of having anonymous classes, it is very helpful during development to just try something out without having the burden of creating a new file and a complete class including namespace and use declarations, etc. I don't buy this argument. If your class loader or PSR prevents you from temporarily adding a 2nd bogus class to the same file (not talking about best practices here, obviously) then there's the culprit and it's nothing the language needs to fix. ~Florian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Anonymous Classes
On Tue, Feb 24, 2015 at 5:19 PM, Philip Sturgeon pjsturg...@gmail.com
wrote:
On Tue, Feb 24, 2015 at 9:10 AM, Dmitry Stogov dmi...@zend.com wrote:
I think the proposal is a bit incomplete.
It's possible to instantiate an anonymous class, but currently it's not
possible to do with them anything else (assign to variable, pass to
function, etc). Something similar to Closure objects should be
introduced.
Thanks. Dmitry.
1. You can absolutely assign the instantiated classes to variables.
Check out this test in the patch:
https://github.com/krakjoe/php-src/compare/anon#diff-25e330fb5a98810de178a5b798102d01R1
In tests you assign instantiated objects.
$a = new class {...};
$b = new class {...};
I'm talking about classes as first class objects.
$c = class {...};
$a = new $c;
$b = new $c;
2. Why do you say they cannot be passed to a function? I can add a
test if you can give me an example of what you're suggesting doesn't
work.
3. Not sure why we'd need a Closure-alike object. Anonymous classes
are just a class, and classes have all the types and hinting
functionality of regular classes. You don't need to implement a class
to let people know its a class.
Maybe you could expand on that a bit? :)
I tried it in the example above.
Also, classes may be useful without objects at all (just static properties
and methods).
$c = class {...};
$c::static_foo();
Thanks. Dmitry.
Re: [PHP-DEV] [RFC] Anonymous Classes
Hi Phil, Am 24.02.2015 um 14:52 schrieb Philip Sturgeon: https://wiki.php.net/rfc/anonymous_classes I like the idea of having anonymous classes, it is very helpful during development to just try something out without having the burden of creating a new file and a complete class including namespace and use declarations, etc. A great feature of anonymous classes in Java is their ability to access the private/protected properties of the object they are defined in, similar to what Closures do in PHP. The thing is, in Java if you access a variable (without this.), it may be of the current scope, a member of the current class or a member of the class where the anonymous class was defined in. In PHP, you have to use $this- to access class members of the anonymous class but there is some $outer- or similar variable missing for the access. You can as a work around pass all members by reference via the constructor, but that is really not nice. In addition, if you define an anonymous class inside a real class and pass another instance of the outer class, the anonymous class can still access the private/protected methods imho. Any thoughts how to handle this or should we just ignore it for now? Second thing is serialization. PHP closures can not be serialized, does the same apply for anonymous classes? It would be really nice if such anonymous classes could e.g. send via a command bus or something to be executed on another host. Thanks Dennis P.s.: there is a footnote in the RFC that does not belong there is think -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Anonymous Classes
I think the proposal is a bit incomplete. It's possible to instantiate an anonymous class, but currently it's not possible to do with them anything else (assign to variable, pass to function, etc). Something similar to Closure objects should be introduced. Thanks. Dmitry. On Tue, Feb 24, 2015 at 4:52 PM, Philip Sturgeon pjsturg...@gmail.com wrote: Good day! https://wiki.php.net/rfc/anonymous_classes There's a little RFC + patch that Joe Watkins put together, and as before with the ArrayOf RFC, I'll be helping out. So, lets get this discussion rolling. It was declined for PHP 5 some time ago, and has returned now to try for PHP 7. The usage of anonymous classes to some will be instantly offensive, but really it comes down to the use case. The usage of anonymous functions compared to declared functions is pretty much the exact same thing as anonymous classes. Other than examples on the RFC, Fractal would certainly be happy to have them: http://fractal.thephpleague.com/transformers/ Defining a class properly is certainly still going to be the majority of uses of classes in PHP. That helps with the Optimizer, and helps code reuse. Sadly due to the way in which people have had ONE CLASS ONE FILE drilled into their head since PEAR and continuing through Zend and PSR-0, it can become a PITA to add some simple functionality if a small class is needed for one tiny thing. Anonymous functions alleviate that annoyance with a simple and consistent feature that just give people a nice simple option to get their jobs done, without hitting autoloaders and file systems to do it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Anonymous Classes
On 02/24/2015 04:31 PM, Philip Sturgeon wrote: On Tue, Feb 24, 2015 at 9:58 AM, Florian Anderiasch m...@anderiasch.de wrote: On 02/24/2015 03:29 PM, Dennis Birkholz wrote: Am 24.02.2015 um 14:52 schrieb Philip Sturgeon: https://wiki.php.net/rfc/anonymous_classes I like the idea of having anonymous classes, it is very helpful during development to just try something out without having the burden of creating a new file and a complete class including namespace and use declarations, etc. I don't buy this argument. If your class loader or PSR prevents you from temporarily adding a 2nd bogus class to the same file (not talking about best practices here, obviously) then there's the culprit and it's nothing the language needs to fix. Your reply seems to assume that avoiding rules in a PSR is the only benefit of the RFC, which is weird when there is a whole RFC full of benefits of this RFC. My reply was simply re: the quoted paragraph in the mail I directly replied to, not yours. I simply think trying something out is not a valid use case of anonymous classes. I can generally like the RFC and still refute arguments in favor of it, right? :) ~Florian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Anonymous Classes
On Tue, Feb 24, 2015 at 10:59 AM, Florian Anderiasch m...@anderiasch.de wrote: On 02/24/2015 04:31 PM, Philip Sturgeon wrote: On Tue, Feb 24, 2015 at 9:58 AM, Florian Anderiasch m...@anderiasch.de wrote: On 02/24/2015 03:29 PM, Dennis Birkholz wrote: Am 24.02.2015 um 14:52 schrieb Philip Sturgeon: https://wiki.php.net/rfc/anonymous_classes I like the idea of having anonymous classes, it is very helpful during development to just try something out without having the burden of creating a new file and a complete class including namespace and use declarations, etc. I don't buy this argument. If your class loader or PSR prevents you from temporarily adding a 2nd bogus class to the same file (not talking about best practices here, obviously) then there's the culprit and it's nothing the language needs to fix. Your reply seems to assume that avoiding rules in a PSR is the only benefit of the RFC, which is weird when there is a whole RFC full of benefits of this RFC. My reply was simply re: the quoted paragraph in the mail I directly replied to, not yours. I simply think trying something out is not a valid use case of anonymous classes. I can generally like the RFC and still refute arguments in favor of it, right? :) ~Florian I gotcha. Again though, Dennis wasn't saying trying something out is the only benefit, just the one. We can take that argument and shove it under the rug for sure, but it's perfectly reasonable for me as one of many arguments for it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Anonymous Classes
On Tue, Feb 24, 2015 at 7:52 AM, Philip Sturgeon pjsturg...@gmail.com wrote:
Good day!
https://wiki.php.net/rfc/anonymous_classes
There's a little RFC + patch that Joe Watkins put together, and as
before with the ArrayOf RFC, I'll be helping out.
So, lets get this discussion rolling.
Anonymous classes open up slightly new ways to do things. I like to
write a lot of small classes for the purposes of DI and re-usability.
Because of that, the code often looks like:
$foo = new Foo($depend1, $depend2, function() {
return 'my custom behavior';
});
That's fine when there's only one callback needed, but beyond that it
breaks down. This becomes more readable:
abstract class Foo
{
...
}
$foo = new class($depend1, $depend2) extends Foo {
public function doFoo() {
}
public function doBar() {
}
}
These cases for me are always single-use for the scope of the
application, and often it's inside configuration blocks that are
custom per environment. I have no need to name the class other than
PHP doesn't support anonymous ones.
I'm +1 on the concept, depending on what the maintenance impact that
this would bring to PHP's core. There are enough other ways to
accomplish the same goals that I don't think this is must have, even
though I'd definitely use it.
Regarding this syntax (from other discussions on the list):
$foo = class { };
I think if such a thing were supported, maybe $foo would just be a
ReflectionClass object. (I haven't really thought that one through...)
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Anonymous Classes
Would have been more useful, inline sintex like JSON:
$object =
{
'property': $value,
'method': function (){...}
};
$object-property;
$object-method();
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Anonymous Classes
On Tue, Feb 24, 2015 at 1:37 PM, S.A.N ua.san.a...@gmail.com wrote:
Would have been more useful, inline sintex like JSON:
$object =
{
'property': $value,
'method': function (){...}
};
$object-property;
$object-method();
I know what you're saying here, and object literals like this would be
rather interesting someday. They are, however, quite different to the
concept of anonymous classes.
JSON syntax would make it very hard for the usual PHP functionality to
be used. Properties and methods look the same, visibility scopes
cannot be used, implementing interfaces becomes impossible, traits
dont have a home, etc. By the time you have catered to all of that you
have something very different to JSON, and very different to PHP.
Or, you have the syntax being proposed here, which is identical to
existing declared class syntax other than there being no name.
Another RFC to replace $foo = (object) [ 'foo' = 'bar' ]; someday
would be nice, but that is not what this is up to.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Anonymous Classes
here is an example for opening a mysqli connection only when the first query is
executed:
$c = new class extends mysqli {
public function query($query, $resultmode = MYSQLI_STORE_RESULT) {
if (empty($this-host_info)) parent::real_connect('127.0.0.1', 'user',
'pwd', 'db');
return parent::query($query, $resultmode);
}
}
// do sth for some time
$-query('...'); // triggers real_connect
$-query('...'); // connection is already established
I haven't tested this, so I'm only intending to present the idea.
Regards
Thomas
Philip Sturgeon wrote on 24.02.2015 14:52:
Good day!
https://wiki.php.net/rfc/anonymous_classes
There's a little RFC + patch that Joe Watkins put together, and as
before with the ArrayOf RFC, I'll be helping out.
So, lets get this discussion rolling.
It was declined for PHP 5 some time ago, and has returned now to try for PHP
7.
The usage of anonymous classes to some will be instantly offensive,
but really it comes down to the use case. The usage of anonymous
functions compared to declared functions is pretty much the exact same
thing as anonymous classes.
Other than examples on the RFC, Fractal would certainly be happy to
have them: http://fractal.thephpleague.com/transformers/
Defining a class properly is certainly still going to be the majority
of uses of classes in PHP. That helps with the Optimizer, and helps
code reuse.
Sadly due to the way in which people have had ONE CLASS ONE FILE
drilled into their head since PEAR and continuing through Zend and
PSR-0, it can become a PITA to add some simple functionality if a
small class is needed for one tiny thing.
Anonymous functions alleviate that annoyance with a simple and
consistent feature that just give people a nice simple option to get
their jobs done, without hitting autoloaders and file systems to do
it.
--
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] Anonymous Classes
On Tue, Feb 24, 2015 at 7:52 AM, Philip Sturgeon pjsturg...@gmail.com wrote: Good day! https://wiki.php.net/rfc/anonymous_classes There's a little RFC + patch that Joe Watkins put together, and as before with the ArrayOf RFC, I'll be helping out. So, lets get this discussion rolling. It was declined for PHP 5 some time ago, and has returned now to try for PHP 7. The usage of anonymous classes to some will be instantly offensive, but really it comes down to the use case. The usage of anonymous functions compared to declared functions is pretty much the exact same thing as anonymous classes. Other than examples on the RFC, Fractal would certainly be happy to have them: http://fractal.thephpleague.com/transformers/ I would also find myself to be a very happy consumer of this. It can provide the opportunity of getting rid of a large amount of boilerplate. In addition, there has been several times when implementing single use extensions for say view libraries (Plates extensions comes to mind) or Plugin handling for things like Zend Framework 2 and there has been several times I utilize a closure with an array to get around having an object simply due to you want to have a callback but with some form of definition. I think there is a very large use case here and something that would be a great addition to the language. Sure, I could make a class and extend it just like this would do but for the convenience of the implementation it is sometimes better to do a simple closure. Defining a class properly is certainly still going to be the majority of uses of classes in PHP. That helps with the Optimizer, and helps code reuse. Sadly due to the way in which people have had ONE CLASS ONE FILE drilled into their head since PEAR and continuing through Zend and PSR-0, it can become a PITA to add some simple functionality if a small class is needed for one tiny thing. I see the point here, but the argument to me seems void. Nothing wrong with a simple class one file for a small class. Anonymous functions alleviate that annoyance with a simple and consistent feature that just give people a nice simple option to get their jobs done, without hitting autoloaders and file systems to do it.
Re: [PHP-DEV] [RFC] Anonymous Classes
On Tue, Feb 24, 2015 at 12:21 PM, Mike Willbanks pen...@gmail.com wrote: On Tue, Feb 24, 2015 at 7:52 AM, Philip Sturgeon pjsturg...@gmail.com wrote: Good day! https://wiki.php.net/rfc/anonymous_classes There's a little RFC + patch that Joe Watkins put together, and as before with the ArrayOf RFC, I'll be helping out. So, lets get this discussion rolling. It was declined for PHP 5 some time ago, and has returned now to try for PHP 7. The usage of anonymous classes to some will be instantly offensive, but really it comes down to the use case. The usage of anonymous functions compared to declared functions is pretty much the exact same thing as anonymous classes. Other than examples on the RFC, Fractal would certainly be happy to have them: http://fractal.thephpleague.com/transformers/ I would also find myself to be a very happy consumer of this. It can provide the opportunity of getting rid of a large amount of boilerplate. In addition, there has been several times when implementing single use extensions for say view libraries (Plates extensions comes to mind) or Plugin handling for things like Zend Framework 2 and there has been several times I utilize a closure with an array to get around having an object simply due to you want to have a callback but with some form of definition. I think there is a very large use case here and something that would be a great addition to the language. Sure, I could make a class and extend it just like this would do but for the convenience of the implementation it is sometimes better to do a simple closure. Defining a class properly is certainly still going to be the majority of uses of classes in PHP. That helps with the Optimizer, and helps code reuse. Sadly due to the way in which people have had ONE CLASS ONE FILE drilled into their head since PEAR and continuing through Zend and PSR-0, it can become a PITA to add some simple functionality if a small class is needed for one tiny thing. I see the point here, but the argument to me seems void. Nothing wrong with a simple class one file for a small class. Something doesn't have to be wrong, another approach can just be more convenient, or handy for different use cases. One class one file can be rather slow depending on the autoloader setup, and depending on whether zend optimizer is enabled or not. For a distributed application running on mostly crap shared hosting, relying on Zend Optimizer is not an option, so the more of these little one-class one-file situations you have the worse it becomes. This RFC offers a solution for people that is not Jam a bunch of these classes at the top of the current file or Make a whole load of one-time use classes to avoid that mess, plus people will snort and shame you for failing to follow decade old best practices. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Anonymous Classes
2015-02-24 20:49 GMT+02:00 Philip Sturgeon pjsturg...@gmail.com:
On Tue, Feb 24, 2015 at 1:37 PM, S.A.N ua.san.a...@gmail.com wrote:
Would have been more useful, inline sintex like JSON:
$object =
{
'property': $value,
'method': function (){...}
};
$object-property;
$object-method();
I know what you're saying here, and object literals like this would be
rather interesting someday. They are, however, quite different to the
concept of anonymous classes.
JSON syntax would make it very hard for the usual PHP functionality to
be used. Properties and methods look the same, visibility scopes
cannot be used, implementing interfaces becomes impossible, traits
dont have a home, etc. By the time you have catered to all of that you
have something very different to JSON, and very different to PHP.
Or, you have the syntax being proposed here, which is identical to
existing declared class syntax other than there being no name.
Another RFC to replace $foo = (object) [ 'foo' = 'bar' ]; someday
would be nice, but that is not what this is up to.
Yes, is problem - properties and methods look the same, how to solve
this problem in PHP I do not know.
Perhaps PHP could interpret this code:
$object =
{
'property' = $value,
'method' = function (){...}
};
AS
$object = new class
{
public $property = $value;
public function method (){...}
}
Use case - inline object without inheritance and traits, only the
properties and methods it brief and easily understood JSON syntax, I
think it would be popular with developers of PHP.
Thank.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Anonymous Classes
I'm not sure if json syntax is better than PHP here:
$object = (object)[
'property'=$value,
'method'=function(){...}
];
$object-property;
$object-method-__invoke();
S.A.N wrote on 24.02.2015 19:37:
Would have been more useful, inline sintex like JSON:
$object =
{
'property': $value,
'method': function (){...}
};
$object-property;
$object-method();
--
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] Anonymous Classes
Hi! https://wiki.php.net/rfc/anonymous_classes There's a little RFC + patch that Joe Watkins put together, and as before with the ArrayOf RFC, I'll be helping out. So, lets get this discussion rolling. This is a nice and clear proposal, however I'm not sure I'm completely convinced about the necessity of it. In Java this kind of pattern is used very frequently, because Java is a statically typed language where it is the only way to achieve dynamic interface, and has other capabilities, see below. In PHP, there are other ways (and can be made more ways, such as more support for duck typing). Also, the question arises when comparing this to Java - would anonymous class functions be closures connected to the environment? In Java, they are and that is what they are most frequently used for - to make contextualized callbacks. In PHP, you need special syntax to capture the environment, so how that would work? Also, what about scope access, etc.? Sadly due to the way in which people have had ONE CLASS ONE FILE drilled into their head since PEAR and continuing through Zend and PSR-0, it can become a PITA to add some simple functionality if a small class is needed for one tiny thing. One class/one file may be a good idea in general for a big project, but as they say, any feature that can not be turned off when needed is a bug. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Anonymous Classes
Hi! I like the idea of having anonymous classes, it is very helpful during development to just try something out without having the burden of creating a new file and a complete class including namespace and use declarations, etc. I think this particular argument is a bit backwards. In PHP, you certainly don't need to create new file to just introduce a new class. If you're working within a framework that makes it a problem, time to think if the framework you're using is fit for your purposes. But PHP certainly does not impose such limitations. A great feature of anonymous classes in Java is their ability to access the private/protected properties of the object they are defined in, similar to what Closures do in PHP. The thing is, in Java if you access a variable (without this.), it may be of the current scope, a member of the current class or a member of the class where the anonymous class was defined in. In PHP, you have to use $this- to access class members of That may be a problem to implement, exactly since you need $this in PHP. Second thing is serialization. PHP closures can not be serialized, does the same apply for anonymous classes? It would be really nice if such Serializing is not a problem, unserializing would be - as there may be no class for this object to instantiate. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
On Fri, Sep 27, 2013 at 11:26 AM, Joe Watkins krak...@php.net wrote:
On 09/27/2013 10:42 AM, Terence Copestake wrote:
Just ... Isn't that something, we can simply keep out of _this_ RFC and
create separate RFC(s) for it later? Like it was done with $this in
Closures?
Do we want another 5.3/5.4 closures situation? Why not iron it all out to
begin with?
If there's a sound, logical reason not to implement the functionality in
question, that's fine. I don't understand why we keep reiterating keeping
it simple as if that is in itself an excuse to, in effect, rush it
through
half-baked.
In the RFC, there are use cases citing languages like Java to support this
- a language in which anonymous classes and the methods in which they're
defined, share scope. Can we then say, let's do it because it's useful in
other languages, but let's not offer the functionality that those
languages
do? Also, my proposed use case being practical in the real world hangs on
resolving the scope issue, as I struggle to look past the difficulties I'd
have trying to use this in my code when it's unable to interact with the
object instance in which it is being used.
That's all I'll say on that now; it's becoming circular.
If you want to update my use case in the RFC, here's an expanded example
of
what I imagine. I've lifted code from the documentation for Sentry* and
below it, written an alternative anonymous class API example.
* I have no affiliation with Sentry / other membership packages are
available.
try
{
// Find the user using the user id
$user = Sentry::findUserById(1);
// Log the user in
Sentry::login($user, false);
}
catch (Cartalyst\Sentry\Users\**LoginRequiredException $e)
{
echo 'Login field is required.';
}
catch (Cartalyst\Sentry\Users\**UserNotActivatedException $e)
{
echo 'User not activated.';
}
catch (Cartalyst\Sentry\Users\**UserNotFoundException $e)
{
echo 'User not found.';
}
// Following is only needed if throttle is enabled
catch (Cartalyst\Sentry\Throttling\**UserSuspendedException $e)
{
$time = $throttle-getSuspensionTime()**;
echo User is suspended for [$time] minutes.;
}
catch (Cartalyst\Sentry\Throttling\**UserBannedException $e)
{
echo 'User is banned.';
}
becomes:
$user = Sentry::findUserById(
1,
(new class implements Cartalyst\Sentry\**LoginHandlerInterface
{
public function onLoginRequired()
{
echo 'Login field is required.';
}
public function onUserNotActivated()
{
echo 'User not activated.';
}
public function onUserNotFound()
{
echo 'User not found.';
}
// Following is only needed if throttle is enabled
public function onUserSuspended()
{
$time = $throttle-getSuspensionTime()**;
echo User is suspended for [$time] minutes.;
}
public function onUserBanned()
{
echo 'User is banned.';
}
public function onSuccess()
{
// Log the user in
Sentry::login($user, false);
}
})
);
Because in your rush to get the ironing done, you are burning clothes,
putting big holes in them, and are going to be left with no clothes without
big holes in them ...
What we are introducing here is anonymous classes, not nested classes:
class Outer {
class Inner {
class Again {
class Inner {
}
}
}
}
This requires a way to resolve complex scope issues, these are formally
nested classes, as yet unsupported, formally nested classes might also look
like:
class Outer {
class Inner {
protected class Again {
private class Inner {
}
}
}
}
I appreciate that the only way to do this right now is with anonymous
classes, but if you are doing it with anonymous classes then you, clearly,
do not care about scope.
The solution to the resolution of nested class scope issues does not
belong as part of the RFC introducing anonymous classes but the RFC
introducing nested classes, which is as yet unwritten, but totally doable.
+1000 on keeping this for another RFC, because it's part of another
problem ...
Cheers
Joe
I think you've become confused with my intentions here. My example is not
of the internal workings of an API and I'm certainly not talking about
nested classes. My example is of a third party using an API from the
outside. Currently, the way the package given in my example communicates is
by using exceptions to signal what happened. What I'm demonstrating is that
a more expressive way to do this would be to instead pass a callback
anonymous class to handle those outcomes, rather than having a series of
catch blocks.
I only think it would be good to actually discuss
Re: [PHP-DEV] RFC: Anonymous Classes
On 10/01/2013 01:19 PM, Terence Copestake wrote:
On Fri, Sep 27, 2013 at 11:26 AM, Joe Watkins krak...@php.net wrote:
On 09/27/2013 10:42 AM, Terence Copestake wrote:
Just ... Isn't that something, we can simply keep out of _this_ RFC and
create separate RFC(s) for it later? Like it was done with $this in
Closures?
Do we want another 5.3/5.4 closures situation? Why not iron it all out to
begin with?
If there's a sound, logical reason not to implement the functionality in
question, that's fine. I don't understand why we keep reiterating keeping
it simple as if that is in itself an excuse to, in effect, rush it
through
half-baked.
In the RFC, there are use cases citing languages like Java to support this
- a language in which anonymous classes and the methods in which they're
defined, share scope. Can we then say, let's do it because it's useful in
other languages, but let's not offer the functionality that those
languages
do? Also, my proposed use case being practical in the real world hangs on
resolving the scope issue, as I struggle to look past the difficulties I'd
have trying to use this in my code when it's unable to interact with the
object instance in which it is being used.
That's all I'll say on that now; it's becoming circular.
If you want to update my use case in the RFC, here's an expanded example
of
what I imagine. I've lifted code from the documentation for Sentry* and
below it, written an alternative anonymous class API example.
* I have no affiliation with Sentry / other membership packages are
available.
try
{
// Find the user using the user id
$user = Sentry::findUserById(1);
// Log the user in
Sentry::login($user, false);
}
catch (Cartalyst\Sentry\Users\**LoginRequiredException $e)
{
echo 'Login field is required.';
}
catch (Cartalyst\Sentry\Users\**UserNotActivatedException $e)
{
echo 'User not activated.';
}
catch (Cartalyst\Sentry\Users\**UserNotFoundException $e)
{
echo 'User not found.';
}
// Following is only needed if throttle is enabled
catch (Cartalyst\Sentry\Throttling\**UserSuspendedException $e)
{
$time = $throttle-getSuspensionTime()**;
echo User is suspended for [$time] minutes.;
}
catch (Cartalyst\Sentry\Throttling\**UserBannedException $e)
{
echo 'User is banned.';
}
becomes:
$user = Sentry::findUserById(
1,
(new class implements Cartalyst\Sentry\**LoginHandlerInterface
{
public function onLoginRequired()
{
echo 'Login field is required.';
}
public function onUserNotActivated()
{
echo 'User not activated.';
}
public function onUserNotFound()
{
echo 'User not found.';
}
// Following is only needed if throttle is enabled
public function onUserSuspended()
{
$time = $throttle-getSuspensionTime()**;
echo User is suspended for [$time] minutes.;
}
public function onUserBanned()
{
echo 'User is banned.';
}
public function onSuccess()
{
// Log the user in
Sentry::login($user, false);
}
})
);
Because in your rush to get the ironing done, you are burning clothes,
putting big holes in them, and are going to be left with no clothes without
big holes in them ...
What we are introducing here is anonymous classes, not nested classes:
class Outer {
class Inner {
class Again {
class Inner {
}
}
}
}
This requires a way to resolve complex scope issues, these are formally
nested classes, as yet unsupported, formally nested classes might also look
like:
class Outer {
class Inner {
protected class Again {
private class Inner {
}
}
}
}
I appreciate that the only way to do this right now is with anonymous
classes, but if you are doing it with anonymous classes then you, clearly,
do not care about scope.
The solution to the resolution of nested class scope issues does not
belong as part of the RFC introducing anonymous classes but the RFC
introducing nested classes, which is as yet unwritten, but totally doable.
+1000 on keeping this for another RFC, because it's part of another
problem ...
Cheers
Joe
I think you've become confused with my intentions here. My example is not
of the internal workings of an API and I'm certainly not talking about
nested classes. My example is of a third party using an API from the
outside. Currently, the way the package given in my example communicates is
by using exceptions to signal what happened. What I'm demonstrating is that
a more expressive way to do this would be to instead pass a callback
anonymous class to handle those outcomes, rather than having a series of
catch blocks.
I only think it would be good to actually discuss (i.e.
Re: [PHP-DEV] RFC: Anonymous Classes
If you need access to the methods in AProxifier then why does the anonymous
class extend A, you should extend AProxifier as you would with any other
class.
Because A has the behavior I want to extend?
An other example:
class A {...}
class B {...}
class Factory
{
protected function protectedMethod() {...}
function getA()
{
return new class extends A {.. call Factory::protectedMethod()? ..};
}
function getB()
{
return new class extends B {.. call Factory::protectedMethod()? ..};
}
}
This is possible and welcomed with closures.
I see it as useful for anonymous classes than it is for anonymous functions.
What do others you think about it?
Re: [PHP-DEV] RFC: Anonymous Classes
On 27 September 2013 09:55, Nicolas Grekas nicolas.grekas+...@gmail.com wrote:
If you need access to the methods in AProxifier then why does the anonymous
class extend A, you should extend AProxifier as you would with any other
class.
Because A has the behavior I want to extend?
An other example:
class A {...}
class B {...}
class Factory
{
protected function protectedMethod() {...}
function getA()
{
return new class extends A {.. call Factory::protectedMethod()? ..};
}
function getB()
{
return new class extends B {.. call Factory::protectedMethod()? ..};
}
}
This is possible and welcomed with closures.
I see it as useful for anonymous classes than it is for anonymous functions.
What do others you think about it?
-1
Just because a closure is an anonymous function does not mean that an
anonymous class has closure capabilites.
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
2013/9/27 Michael Wallner m...@php.net
On 27 September 2013 09:55, Nicolas Grekas nicolas.grekas+...@gmail.com
wrote:
If you need access to the methods in AProxifier then why does the
anonymous
class extend A, you should extend AProxifier as you would with any other
class.
Because A has the behavior I want to extend?
An other example:
class A {...}
class B {...}
class Factory
{
protected function protectedMethod() {...}
function getA()
{
return new class extends A {.. call Factory::protectedMethod()?
..};
}
function getB()
{
return new class extends B {.. call Factory::protectedMethod()?
..};
}
}
This is possible and welcomed with closures.
I see it as useful for anonymous classes than it is for anonymous
functions.
What do others you think about it?
-1
Just because a closure is an anonymous function does not mean that an
anonymous class has closure capabilites.
Just ... Isn't that something, we can simply keep out of _this_ RFC and
create separate RFC(s) for it later? Like it was done with $this in
Closures?
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] RFC: Anonymous Classes
Just ... Isn't that something, we can simply keep out of _this_ RFC and
create separate RFC(s) for it later? Like it was done with $this in
Closures?
Do we want another 5.3/5.4 closures situation? Why not iron it all out to
begin with?
If there's a sound, logical reason not to implement the functionality in
question, that's fine. I don't understand why we keep reiterating keeping
it simple as if that is in itself an excuse to, in effect, rush it through
half-baked.
In the RFC, there are use cases citing languages like Java to support this
- a language in which anonymous classes and the methods in which they're
defined, share scope. Can we then say, let's do it because it's useful in
other languages, but let's not offer the functionality that those languages
do? Also, my proposed use case being practical in the real world hangs on
resolving the scope issue, as I struggle to look past the difficulties I'd
have trying to use this in my code when it's unable to interact with the
object instance in which it is being used.
That's all I'll say on that now; it's becoming circular.
If you want to update my use case in the RFC, here's an expanded example of
what I imagine. I've lifted code from the documentation for Sentry* and
below it, written an alternative anonymous class API example.
* I have no affiliation with Sentry / other membership packages are
available.
try
{
// Find the user using the user id
$user = Sentry::findUserById(1);
// Log the user in
Sentry::login($user, false);
}
catch (Cartalyst\Sentry\Users\LoginRequiredException $e)
{
echo 'Login field is required.';
}
catch (Cartalyst\Sentry\Users\UserNotActivatedException $e)
{
echo 'User not activated.';
}
catch (Cartalyst\Sentry\Users\UserNotFoundException $e)
{
echo 'User not found.';
}
// Following is only needed if throttle is enabled
catch (Cartalyst\Sentry\Throttling\UserSuspendedException $e)
{
$time = $throttle-getSuspensionTime();
echo User is suspended for [$time] minutes.;
}
catch (Cartalyst\Sentry\Throttling\UserBannedException $e)
{
echo 'User is banned.';
}
becomes:
$user = Sentry::findUserById(
1,
(new class implements Cartalyst\Sentry\LoginHandlerInterface
{
public function onLoginRequired()
{
echo 'Login field is required.';
}
public function onUserNotActivated()
{
echo 'User not activated.';
}
public function onUserNotFound()
{
echo 'User not found.';
}
// Following is only needed if throttle is enabled
public function onUserSuspended()
{
$time = $throttle-getSuspensionTime();
echo User is suspended for [$time] minutes.;
}
public function onUserBanned()
{
echo 'User is banned.';
}
public function onSuccess()
{
// Log the user in
Sentry::login($user, false);
}
})
);
Re: [PHP-DEV] RFC: Anonymous Classes
On 09/27/2013 10:42 AM, Terence Copestake wrote:
Just ... Isn't that something, we can simply keep out of _this_ RFC and
create separate RFC(s) for it later? Like it was done with $this in
Closures?
Do we want another 5.3/5.4 closures situation? Why not iron it all out to
begin with?
If there's a sound, logical reason not to implement the functionality in
question, that's fine. I don't understand why we keep reiterating keeping
it simple as if that is in itself an excuse to, in effect, rush it through
half-baked.
In the RFC, there are use cases citing languages like Java to support this
- a language in which anonymous classes and the methods in which they're
defined, share scope. Can we then say, let's do it because it's useful in
other languages, but let's not offer the functionality that those languages
do? Also, my proposed use case being practical in the real world hangs on
resolving the scope issue, as I struggle to look past the difficulties I'd
have trying to use this in my code when it's unable to interact with the
object instance in which it is being used.
That's all I'll say on that now; it's becoming circular.
If you want to update my use case in the RFC, here's an expanded example of
what I imagine. I've lifted code from the documentation for Sentry* and
below it, written an alternative anonymous class API example.
* I have no affiliation with Sentry / other membership packages are
available.
try
{
// Find the user using the user id
$user = Sentry::findUserById(1);
// Log the user in
Sentry::login($user, false);
}
catch (Cartalyst\Sentry\Users\LoginRequiredException $e)
{
echo 'Login field is required.';
}
catch (Cartalyst\Sentry\Users\UserNotActivatedException $e)
{
echo 'User not activated.';
}
catch (Cartalyst\Sentry\Users\UserNotFoundException $e)
{
echo 'User not found.';
}
// Following is only needed if throttle is enabled
catch (Cartalyst\Sentry\Throttling\UserSuspendedException $e)
{
$time = $throttle-getSuspensionTime();
echo User is suspended for [$time] minutes.;
}
catch (Cartalyst\Sentry\Throttling\UserBannedException $e)
{
echo 'User is banned.';
}
becomes:
$user = Sentry::findUserById(
1,
(new class implements Cartalyst\Sentry\LoginHandlerInterface
{
public function onLoginRequired()
{
echo 'Login field is required.';
}
public function onUserNotActivated()
{
echo 'User not activated.';
}
public function onUserNotFound()
{
echo 'User not found.';
}
// Following is only needed if throttle is enabled
public function onUserSuspended()
{
$time = $throttle-getSuspensionTime();
echo User is suspended for [$time] minutes.;
}
public function onUserBanned()
{
echo 'User is banned.';
}
public function onSuccess()
{
// Log the user in
Sentry::login($user, false);
}
})
);
Because in your rush to get the ironing done, you are burning clothes,
putting big holes in them, and are going to be left with no clothes
without big holes in them ...
What we are introducing here is anonymous classes, not nested classes:
class Outer {
class Inner {
class Again {
class Inner {
}
}
}
}
This requires a way to resolve complex scope issues, these are formally
nested classes, as yet unsupported, formally nested classes might also
look like:
class Outer {
class Inner {
protected class Again {
private class Inner {
}
}
}
}
I appreciate that the only way to do this right now is with anonymous
classes, but if you are doing it with anonymous classes then you,
clearly, do not care about scope.
The solution to the resolution of nested class scope issues does not
belong as part of the RFC introducing anonymous classes but the RFC
introducing nested classes, which is as yet unwritten, but totally doable.
+1000 on keeping this for another RFC, because it's part of another
problem ...
Cheers
Joe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
hi Joe! On Thu, Sep 26, 2013 at 8:59 AM, Joe Watkins krak...@php.net wrote: Ok, I included just about all the information on use cases that is obvious or has been discussed, so I think we got use cases covered now, right ?? Thanks for the updates! See a good one yet ?? I think it should be enough, and you have my voice now :) As of the other requests here, like nested classes (which I really do not like from a design point of view), I do not think they fit in this RFC. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
On 09/26/2013 01:50 AM, Pierre Joye wrote: hi! On Sun, Sep 22, 2013 at 11:39 PM, Joe Watkins krak...@php.net wrote: Morning All, https://wiki.php.net/rfc/anonymous_classes I'd like to hear thoughts regarding the addition of anonymous classes, patch included. Thanks for your proposal and work. If you did not yet update your RFC I would suggest to do so, it is about the right time. Adding already answered questions, more use cases (read a couple of good ones in this thread). It will help to end in circular discussions or arguing. Cheers, Pierre Thanks ... I have made many changes to the RFC and patch since the beginning of this discussion ... It might be useful if you could all now go back to the RFC for another read, point out anything I've left unclear at this point. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
I think what Terence was talking about is more like this:
class A
{
}
class AProxifier
{
protected function protectedMethod() {...}
function getAProxy()
{
return new class extends A { /* How do you call
AProxifier-protectedMethod() here? */ };
}
}
This is possible with anonymous functions, that's a big feature of PHP5.4.
And for the same reasons might be expected here too?
I don't have the answer, just raising the point.
(new class ...
protected $value;
public function __construct($value)
{
$this-value = $value;
}
public function doSomething()
{
echo $this-value;
})($val)
Btw, I can't get used to ($val) beeing at the end of the declaration. I
feel it very confusing.
Nicolas
Re: [PHP-DEV] RFC: Anonymous Classes
Am 26.09.2013 11:29 schrieb Nicolas Grekas nicolas.grekas+...@gmail.com:
Btw, I can't get used to ($val) beeing at the end of the declaration. I
feel it very confusing.
I feel the same. Couldn't this (constructor arguments) be moved?
$that = new class(/* constructor args */) /* extends X implements Y */ {
... class body
};
Re: [PHP-DEV] RFC: Anonymous Classes
On 09/26/2013 10:28 AM, Nicolas Grekas wrote:
I think what Terence was talking about is more like this:
class A
{
}
class AProxifier
{
protected function protectedMethod() {...}
function getAProxy()
{
return new class extends A { /* How do you call
AProxifier-protectedMethod() here? */ };
}
}
This is possible with anonymous functions, that's a big feature of PHP5.4.
And for the same reasons might be expected here too?
I don't have the answer, just raising the point.
(new class ...
protected $value;
public function __construct($value)
{
$this-value = $value;
}
public function doSomething()
{
echo $this-value;
})($val)
Btw, I can't get used to ($val) beeing at the end of the declaration. I
feel it very confusing.
Nicolas
If you need access to the methods in AProxifier then why does the
anonymous class extend A, you should extend AProxifier as you would with
any other class.
class A {
public function __construct(/* ctor args*/) {
/* ctor statements */
}
protected function protectedMethod() {
/* protected method */
}
public function getProxy() {
return new class extends A {
/* proxy stuff */
} (/* ctor args */);
}
}
For the following reasons the syntax should remain as it is:
It keeps the number of conflicts in the parser the same (%expect 3)
It is consistent with anonymous function calls - args after definition
...
It does not make sense to pass arguments to a constructor that might
not yet be declared
It is the simplest syntax to implement .. and so less margin for error,
easier to maintain in the future ...
Cheers
Joe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
2013/9/26 Joe Watkins krak...@php.net On 09/26/2013 01:50 AM, Pierre Joye wrote: hi! On Sun, Sep 22, 2013 at 11:39 PM, Joe Watkins krak...@php.net wrote: Morning All, https://wiki.php.net/rfc/**anonymous_classeshttps://wiki.php.net/rfc/anonymous_classes I'd like to hear thoughts regarding the addition of anonymous classes, patch included. Thanks for your proposal and work. If you did not yet update your RFC I would suggest to do so, it is about the right time. Adding already answered questions, more use cases (read a couple of good ones in this thread). It will help to end in circular discussions or arguing. Cheers, Pierre Thanks ... I have made many changes to the RFC and patch since the beginning of this discussion ... It might be useful if you could all now go back to the RFC for another read, point out anything I've left unclear at this point. Thank you for the updates. There is a possible mistake in the Inheritance section. The $this-data array is passed by value to the constructor of the anonymous class. Once there is any change to the initial array, the two classes will contain different data. Which leads us to the point that this pattern is not enough to do what you wanted to without changing the original constructor. This is usually out of the question, as one such change will also change the outer class' behavior. We don't have to reinvent the wheel here. The solution is some kind of use clause that works similarly to the anonymous functions. Cheers, Lazare INEPOLOGLOU Ingénieur Logiciel
Re: [PHP-DEV] RFC: Anonymous Classes
On 09/26/2013 11:38 AM, Lazare Inepologlou wrote: 2013/9/26 Joe Watkins krak...@php.net On 09/26/2013 01:50 AM, Pierre Joye wrote: hi! On Sun, Sep 22, 2013 at 11:39 PM, Joe Watkins krak...@php.net wrote: Morning All, https://wiki.php.net/rfc/**anonymous_classeshttps://wiki.php.net/rfc/anonymous_classes I'd like to hear thoughts regarding the addition of anonymous classes, patch included. Thanks for your proposal and work. If you did not yet update your RFC I would suggest to do so, it is about the right time. Adding already answered questions, more use cases (read a couple of good ones in this thread). It will help to end in circular discussions or arguing. Cheers, Pierre Thanks ... I have made many changes to the RFC and patch since the beginning of this discussion ... It might be useful if you could all now go back to the RFC for another read, point out anything I've left unclear at this point. Thank you for the updates. There is a possible mistake in the Inheritance section. The $this-data array is passed by value to the constructor of the anonymous class. Once there is any change to the initial array, the two classes will contain different data. Which leads us to the point that this pattern is not enough to do what you wanted to without changing the original constructor. This is usually out of the question, as one such change will also change the outer class' behavior. We don't have to reinvent the wheel here. The solution is some kind of use clause that works similarly to the anonymous functions. Cheers, Lazare INEPOLOGLOU Ingénieur Logiciel We don't have to re-invent the wheel, pass by reference if that's what you want to do, the example didn't make any changes to data, tests included with the patch do, and it, of course, works ... Cheers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
On Sep 26, 2013 10:35 AM, Joe Watkins krak...@php.net wrote: Thanks ... I have made many changes to the RFC and patch since the beginning of this discussion ... It might be useful if you could all now go back to the RFC for another read, point out anything I've left unclear at this point. I saw your changes :) I would add more use cases if possible, the more the better. My feeling is that some does not see yet a good use case. It is a known pattern is sometimes not a good enough argument. Cheers,
Re: [PHP-DEV] RFC: Anonymous Classes
Am 26.09.2013 12:16 schrieb Joe Watkins krak...@php.net: For the following reasons the syntax should remain as it is: It is consistent with anonymous function calls - args after definition ... I think it is exceedingly rare for anynomous functions to be called at their point of definition, while the constructor of your anonymous class will alreays be called there. It does not make sense to pass arguments to a constructor that might not yet be declared The constructor will be called after the full class definition has been seen anyway; where the arguments are put syntactically doesn't change that, does it? My proposal ($that = new class(constructor args) places the constructor args in exactly the same place they are when instantiating a nonanonymous class. best regards Patrick
Re: [PHP-DEV] RFC: Anonymous Classes
On 09/26/2013 01:00 PM, Pierre Joye wrote: On Sep 26, 2013 10:35 AM, Joe Watkins krak...@php.net wrote: Thanks ... I have made many changes to the RFC and patch since the beginning of this discussion ... It might be useful if you could all now go back to the RFC for another read, point out anything I've left unclear at this point. I saw your changes :) I would add more use cases if possible, the more the better. My feeling is that some does not see yet a good use case. It is a known pattern is sometimes not a good enough argument. Cheers, Ok, I included just about all the information on use cases that is obvious or has been discussed, so I think we got use cases covered now, right ?? See a good one yet ?? Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
On Thu, Sep 26, 2013 at 5:59 PM, Joe Watkins krak...@php.net wrote:
Ok, I included just about all the information on use cases that is obvious
or has been discussed, so I think we got use cases covered now, right ??
See a good one yet ??
Cheers
Joe
Wondering about scoping. Yes, anonymous classes can have their own
constructor, but if we're adding syntactic sugar why not make it
possible to use from the scope they're created in?
See this example adapted from a Stack Overflow question about how it
works in Java [1]:
(not sure how you the use syntax should look like)
public function doStuff($userId) {
$this-doOtherStuff($userId, new class implements SomeInterface {
public function onSuccess() {
echo $userId;
}
});
}
vs
public function doStuff($userId) {
$this-doOtherStuff($userId, new class implements SomeInterface {
private $userId;
public function __construct($userId) {
$this-userId = $userId;
}
public function onSuccess() {
echo $this-userId;
}
});
}
[1]
http://stackoverflow.com/questions/3251018/java-anonymous-inner-class-using-a-local-variable
Cheers,
Alexander
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
I'm growing to like the idea myself. It may create new opportunities for bad practices, but I don't think it's the concern of internals to police how people may or may not use a feature. There are also I think a few things that would need to be addressed before this would be ready for the real world. For example: 1) As hinted at previously, the use statement. Doing this per-method as suggested would be less ambiguous than applying to the whole class - and would also prevent pollution. 2) Transparency between an anonymous class and the class in which it is defined (if any). One thing I found very restrictive about closures back in 5.3 was the lack of $this support. I can imagine that missing functionality being similarly restrictive for these new anonymous classes. Obviously $this itself will be reserved for use by the anonymous class, which means there would need to be an alternative. Passing in a variable is one thing, but as it stands the anon class would then only have public access. Something like $class with similar behaviour to $this could be an option. In Java I believe anonymous classes have the same scope as the method in which they're defined. Would something like this or similar be feasible and permissible in PHP?
Re: [PHP-DEV] RFC: Anonymous Classes
On 09/25/2013 09:59 AM, Terence Copestake wrote: I'm growing to like the idea myself. It may create new opportunities for bad practices, but I don't think it's the concern of internals to police how people may or may not use a feature. There are also I think a few things that would need to be addressed before this would be ready for the real world. For example: 1) As hinted at previously, the use statement. Doing this per-method as suggested would be less ambiguous than applying to the whole class - and would also prevent pollution. 2) Transparency between an anonymous class and the class in which it is defined (if any). One thing I found very restrictive about closures back in 5.3 was the lack of $this support. I can imagine that missing functionality being similarly restrictive for these new anonymous classes. Obviously $this itself will be reserved for use by the anonymous class, which means there would need to be an alternative. Passing in a variable is one thing, but as it stands the anon class would then only have public access. Something like $class with similar behaviour to $this could be an option. In Java I believe anonymous classes have the same scope as the method in which they're defined. Would something like this or similar be feasible and permissible in PHP? 1) Anonymous classes in PHP would support a constructor, so I don't see the need for use to be utilized here, it would just clutter declarations and the patch. 2) Again, constructors can be used, and is less confusing than introducing a new variable, but I'm open to persuasion if the idea is liked in general ... Well, it's likely possible to introduce a shared kind of scope, but I don't really think it's necessary, for the same reasons as 1) and 2). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
1) Anonymous classes in PHP would support a constructor, so I don't see
the need for use to be utilized here, it would just clutter declarations
and the patch.
This works, but it's more effort for the programmer and arguably just
moving the clutter from the declaration to the constructor.
e.g.
(new class ...
protected $value;
public function __construct($value)
{
$this-value = $value;
}
public function doSomething()
{
echo $this-value;
})($val)
vs.
(new class ...
public function doSomething() use ($val)
{
echo $val;
})
It gets even uglier for passing by reference.
2) Again, constructors can be used, and is less confusing than introducing
a new variable, but I'm open to persuasion if the idea is liked in general
...
This is fine when working with only a handful of values, but what about
needing access to a large number of values? What about making (especially
protected) method calls within the anon class?
Along the same vein, why did we even bother having use and $this for
closures, if you can after all just pass everything as arguments?
If there are realistic and elegant alternative solutions to the problems
presented, that's fair enough. Rejecting something because it's not as
simple to implement and you can hack around it in user code anyway...
that's a dangerous way to go about your business.
Re: [PHP-DEV] RFC: Anonymous Classes
On 09/25/2013 02:02 PM, Terence Copestake wrote:
1) Anonymous classes in PHP would support a constructor, so I don't see
the need for use to be utilized here, it would just clutter declarations
and the patch.
This works, but it's more effort for the programmer and arguably just
moving the clutter from the declaration to the constructor.
e.g.
(new class ...
protected $value;
public function __construct($value)
{
$this-value = $value;
}
public function doSomething()
{
echo $this-value;
})($val)
vs.
(new class ...
public function doSomething() use ($val)
{
echo $val;
})
It gets even uglier for passing by reference.
2) Again, constructors can be used, and is less confusing than introducing
a new variable, but I'm open to persuasion if the idea is liked in general
...
This is fine when working with only a handful of values, but what about
needing access to a large number of values? What about making (especially
protected) method calls within the anon class?
Along the same vein, why did we even bother having use and $this for
closures, if you can after all just pass everything as arguments?
If there are realistic and elegant alternative solutions to the problems
presented, that's fair enough. Rejecting something because it's not as
simple to implement and you can hack around it in user code anyway...
that's a dangerous way to go about your business.
The first example doesn't make good sense:
(new class ...
protected $value;
public function __construct($value)
{
$this-value = $value;
}
public function doSomething()
{
echo $this-value;
})($val)
If $value is protected then how are you passing it in from outside as $val ?
If your anonymous class needs access to protected methods (which in turn
might want to read private members) then there's already an established
way of declaring that:
?php
class Outer {
private $dice;
public function __construct($dice) {
$this-dice = $dice;
}
protected function protectedMethod() {
return $this-dice;
}
public function publicMethod() {
return new class extends Outer {
public function forwardToProtectedMethod() {
$this-protectedMethod();
}
}($this);
}
}
var_dump((new Outer($_SERVER))-publicMethod());
?
This works now, as you expect it too ... not elegant enough ?? you don't
think use() everywhere might be a little bit much ??
Lets try to keep it as simple as possible, I think ...
Cheers
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
hi! On Sun, Sep 22, 2013 at 11:39 PM, Joe Watkins krak...@php.net wrote: Morning All, https://wiki.php.net/rfc/anonymous_classes I'd like to hear thoughts regarding the addition of anonymous classes, patch included. Thanks for your proposal and work. If you did not yet update your RFC I would suggest to do so, it is about the right time. Adding already answered questions, more use cases (read a couple of good ones in this thread). It will help to end in circular discussions or arguing. Cheers, Pierre
Re: [PHP-DEV] RFC: Anonymous Classes
Lazare Inepologlou linep...@gmail.com schrieb: I use anonymous classes very frequently in Java and in C#, and I would say that they are quite useful. However the examples given in the RFC are really bad ones. Why on earth would you need a constructor for an anonymous class? Anonymous classes are used to implement quickly some interface. Frankly, constructors are not part of any interface. Besides a constructor is totally useless in an anonymous class as it will never be called after the object is created. The need for anonymous classes in Java mostly comes from implementing interfaces on demand due to the lack of lamdas and the requirements of a strongly typed language. PHP has lambdas and it doesn't require you to match typing. Therefore I think the preferred way for most of the use cases is to use a lambda or if a bigger implementation is necessary, to give it a name. Due to namespacing you don't pollute the global scope anyway. Therefore I don't see much reason left as to why add anonymous classes and I really have a hard time finding a use case, except for trying to write PHP as you would write Java (which most likely is a bad idea). - David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
2013/9/24 David Soria Parra d...@php.net
Lazare Inepologlou linep...@gmail.com schrieb:
I use anonymous classes very frequently in Java and in C#, and I would
say
that they are quite useful. However the examples given in the RFC are
really bad ones. Why on earth would you need a constructor for an
anonymous
class? Anonymous classes are used to implement quickly some interface.
Frankly, constructors are not part of any interface. Besides a
constructor
is totally useless in an anonymous class as it will never be called after
the object is created.
The need for anonymous classes in Java mostly comes from implementing
interfaces on demand due to the lack of lamdas and the requirements of
a strongly typed language. PHP has lambdas and it doesn't require you
to match typing. Therefore I think the preferred way for most of the
use cases is to use a lambda or if a bigger implementation is necessary,
to give it a name. Due to namespacing you don't pollute the global scope
anyway. Therefore I don't see much reason left as to why add anonymous
classes and I really have a hard time finding a use case, except for trying
to write PHP as you would write Java (which most likely is a bad idea).
There are many use cases where anonymous classes are useful, even in the
presence of lambdas. I use them quite often when dealing with graphical
interfaces and templates. Here is an example:
abstract class MyFancyHtmlListView extends UI {
protected function IsHeaderVisible(){ return true; }
protected function GetListItemMenu(){ return null; }
protected function OnItemClick( $item ){ }
protected abstract function RenderListItem( $item );
public function Render(){
// echo ...
}
}
With anonymous classes we could do something like this:
?= new MyFancyHtmlListView(){
protected function IsHeaderVisible(){
return false;
}
protected function RenderListItem( $item ){
// echo ...
}
} ?
The biggest advantage is that a missing RenderListItem could be statically
verified.
It is just a pattern that follows a different way of thinking: Instead of
having a list of parameters (including lambdas), we have standard methods
that take advantage of all the nice properties of OOP such as abstraction,
inheritance and polymorphism.
Lazare INEPOLOGLOU
Ingénieur Logiciel
Re: [PHP-DEV] RFC: Anonymous Classes
Playing devil's advocate here, could this feature make the language more expressive? Take for example an API where you'd typically wrap a method call in try/catch blocks to handle the various outcomes e.g. a user login, you'd maybe have a UserDisabled exception, a UserAlreadyLoggedIn exception, a UserPasswordIncorrect exception, etc. With the addition of this syntactic sugar, the method could instead accept an anonymous class with a onDisabled, onLoggedIn, onPasswordIncorrect methods. Perhaps it would also have a performance benefit over cascading through catch blocks? Though someone else would have to confirm that.
Re: [PHP-DEV] RFC: Anonymous Classes
On Tue, Sep 24, 2013 at 8:25 AM, Terence Copestake terence.copest...@gmail.com wrote: Playing devil's advocate here, could this feature make the language more expressive? Take for example an API where you'd typically wrap a method call in try/catch blocks to handle the various outcomes e.g. a user login, you'd maybe have a UserDisabled exception, a UserAlreadyLoggedIn exception, a UserPasswordIncorrect exception, etc. With the addition of this syntactic sugar, the method could instead accept an anonymous class with a onDisabled, onLoggedIn, onPasswordIncorrect methods. Perhaps it would also have a performance benefit over cascading through catch blocks? Though someone else would have to confirm that. Why wouldn't you want this to a concrete, real class? I don't see the benefit, in your example, of doing an anonymous class vs defining an actual class and passing that in as the handler.
Re: [PHP-DEV] RFC: Anonymous Classes
What about allowing a use statement on these methods?
$someFoo = bar;
$object = new class{
function method() use ($someFoo) { return $someFoo;}
}
$object-method(); // bar;
Re: [PHP-DEV] RFC: Anonymous Classes
On 24 September 2013 14:51, Nicolas Grekas nicolas.grekas+...@gmail.comwrote:
What about allowing a use statement on these methods?
$someFoo = bar;
$object = new class{
function method() use ($someFoo) { return $someFoo;}
}
$object-method(); // bar;
I think the idea of anonymous classes is very useful.
a use case that I recently encountered, is to override a specific method in
a class.
So instead of creating a new class that extends the original class, you can
just use an anonymous class and override the methods that you want.
E.G.
You can to the following:
use Symfony\Component\Process\Process;
$process = new class extends Process {
public function start() {
/* ... */
}
};
instead of the following:
namespace My\Namespace\Process;
use Symfony\Component\Process\Process as Base;
class Process extends Base {
public function start() {
/* ... */
}
}
$process = new \My\Namespace\Process\Process;
Re: [PHP-DEV] RFC: Anonymous Classes
On 09/24/2013 01:30 PM, Kristopher wrote: On Tue, Sep 24, 2013 at 8:25 AM, Terence Copestake terence.copest...@gmail.com wrote: Playing devil's advocate here, could this feature make the language more expressive? Take for example an API where you'd typically wrap a method call in try/catch blocks to handle the various outcomes e.g. a user login, you'd maybe have a UserDisabled exception, a UserAlreadyLoggedIn exception, a UserPasswordIncorrect exception, etc. With the addition of this syntactic sugar, the method could instead accept an anonymous class with a onDisabled, onLoggedIn, onPasswordIncorrect methods. Perhaps it would also have a performance benefit over cascading through catch blocks? Though someone else would have to confirm that. Why wouldn't you want this to a concrete, real class? I don't see the benefit, in your example, of doing an anonymous class vs defining an actual class and passing that in as the handler. People express themselves in different ways ... It is mostly just about expressing the same thing in different ways, we can find justification for it when pushed, because we are being pushed ... I'm a bit confused by this idea that every RFC has to be accompanied by a long list of use cases, expressing ideas that cannot conceivably be expressed any other way ... that doesn't make any sense, you can do almost anything a bunch of ways ... I think enough use cases have been provided, it's an established, widely used, part of OO elsewhere: The _only_ question is should we have it, which is incidentally the reason the RFC was sparse in the first place ... Cheers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: Anonymous Classes
-Original Message- From: Joe Watkins [mailto:krak...@php.net] Sent: Tuesday, September 24, 2013 10:08 PM To: internals@lists.php.net; Kristopher Subject: Re: [PHP-DEV] RFC: Anonymous Classes On 09/24/2013 01:30 PM, Kristopher wrote: On Tue, Sep 24, 2013 at 8:25 AM, Terence Copestake terence.copest...@gmail.com wrote: Playing devil's advocate here, could this feature make the language more expressive? Take for example an API where you'd typically wrap a method call in try/catch blocks to handle the various outcomes e.g. a user login, you'd maybe have a UserDisabled exception, a UserAlreadyLoggedIn exception, a UserPasswordIncorrect exception, etc. With the addition of this syntactic sugar, the method could instead accept an anonymous class with a onDisabled, onLoggedIn, onPasswordIncorrect methods. Perhaps it would also have a performance benefit over cascading through catch blocks? Though someone else would have to confirm that. Why wouldn't you want this to a concrete, real class? I don't see the benefit, in your example, of doing an anonymous class vs defining an actual class and passing that in as the handler. People express themselves in different ways ... It is mostly just about expressing the same thing in different ways, we can find justification for it when pushed, because we are being pushed ... I'm a bit confused by this idea that every RFC has to be accompanied by a long list of use cases, expressing ideas that cannot conceivably be expressed any other way ... that doesn't make any sense, you can do almost anything a bunch of ways ... [Robert Stoll] Every syntactic sugar means more overhead for maintaining PHP and therefore I think it is a good idea to review the idea and ask for real use cases. However, real use cases were presented in this case which makes sense IMO and thus I think the RFC should be accepted. I am not a fan of anonymous classes with lot of logic in it, but small anonymous classes can be very useful as presented before. One additional use case I can think of is a composition where it is not exposed to the outside of the class. An anonymous class extending a small interface or extending an abstract class with only a few methods seems to be the suitable candidate here IMO. If PHP would support inner classes I would probably prefer a private inner class when the anonymous class starts to hold to much logic. Cheers, Robert I think enough use cases have been provided, it's an established, widely used, part of OO elsewhere: The _only_ question is should we have it, which is incidentally the reason the RFC was sparse in the first place ... Cheers -- 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: Anonymous Classes
On 09/24/2013 09:50 PM, Robert Stoll wrote: -Original Message- From: Joe Watkins [mailto:krak...@php.net] Sent: Tuesday, September 24, 2013 10:08 PM To: internals@lists.php.net; Kristopher Subject: Re: [PHP-DEV] RFC: Anonymous Classes On 09/24/2013 01:30 PM, Kristopher wrote: On Tue, Sep 24, 2013 at 8:25 AM, Terence Copestake terence.copest...@gmail.com wrote: Playing devil's advocate here, could this feature make the language more expressive? Take for example an API where you'd typically wrap a method call in try/catch blocks to handle the various outcomes e.g. a user login, you'd maybe have a UserDisabled exception, a UserAlreadyLoggedIn exception, a UserPasswordIncorrect exception, etc. With the addition of this syntactic sugar, the method could instead accept an anonymous class with a onDisabled, onLoggedIn, onPasswordIncorrect methods. Perhaps it would also have a performance benefit over cascading through catch blocks? Though someone else would have to confirm that. Why wouldn't you want this to a concrete, real class? I don't see the benefit, in your example, of doing an anonymous class vs defining an actual class and passing that in as the handler. People express themselves in different ways ... It is mostly just about expressing the same thing in different ways, we can find justification for it when pushed, because we are being pushed ... I'm a bit confused by this idea that every RFC has to be accompanied by a long list of use cases, expressing ideas that cannot conceivably be expressed any other way ... that doesn't make any sense, you can do almost anything a bunch of ways ... [Robert Stoll] Every syntactic sugar means more overhead for maintaining PHP and therefore I think it is a good idea to review the idea and ask for real use cases. However, real use cases were presented in this case which makes sense IMO and thus I think the RFC should be accepted. I am not a fan of anonymous classes with lot of logic in it, but small anonymous classes can be very useful as presented before. One additional use case I can think of is a composition where it is not exposed to the outside of the class. An anonymous class extending a small interface or extending an abstract class with only a few methods seems to be the suitable candidate here IMO. If PHP would support inner classes I would probably prefer a private inner class when the anonymous class starts to hold to much logic. Cheers, Robert I think enough use cases have been provided, it's an established, widely used, part of OO elsewhere: The _only_ question is should we have it, which is incidentally the reason the RFC was sparse in the first place ... Cheers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I think sugar can have overhead ... but did you see the patch ?? In this case, there's not really any use cases you can give that absolutely require anonymous classes, it's personal preference. I'm glad that others found examples of use cases they can give, as that seems required ... I just don't really see the sense in saying that's why we should have it, because absolutely anything suggested can be achieved without it ... It's too simplistic, and wrong, to say that all RFC's require the exact same treatment; they clearly do not. If the idea is simple then the patch, and ideally the process that gets it merged should also be simple. Thanks for all the input, everyone, hope this isn't misunderstood ... Inner classes can be done, I mentioned this in the RFC, there's a patch to play with, I've not really given it a bunch of thought, so no draft yet even, I'm just saying, it's a possibility ... Cheers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
On 09/22/2013 11:39 PM, Joe Watkins wrote: https://wiki.php.net/rfc/anonymous_classes I'd like to hear thoughts regarding the addition of anonymous classes, patch included. I am having a hard time picturing a real-world use-case for this. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
2013/9/23 Rasmus Lerdorf ras...@lerdorf.com
On 09/22/2013 11:39 PM, Joe Watkins wrote:
https://wiki.php.net/rfc/anonymous_classes
I'd like to hear thoughts regarding the addition of anonymous
classes, patch included.
I am having a hard time picturing a real-world use-case for this.
The use case is one-time usage of an implementation, where you currently
probably pass callbacks into a Callback*-class like
$x = new CallbackFoo(function() {
/* do something */
});
vs.
$x = new Foo () {
public function doSometing()
{
/* do something */
}
});
Imagine you have several abstract methods in one interface/class, which
would need several callbacks passed to the constructor.
Also '$this' is mapped to the right objects.
Regards,
Sebastian
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] RFC: Anonymous Classes
On 23 September 2013 10:44, Sebastian Krebs krebs@gmail.com wrote:
2013/9/23 Rasmus Lerdorf ras...@lerdorf.com
On 09/22/2013 11:39 PM, Joe Watkins wrote:
https://wiki.php.net/rfc/anonymous_classes
I'd like to hear thoughts regarding the addition of anonymous
classes, patch included.
I am having a hard time picturing a real-world use-case for this.
The use case is one-time usage of an implementation, where you currently
probably pass callbacks into a Callback*-class like
$x = new CallbackFoo(function() {
/* do something */
});
vs.
$x = new Foo () {
public function doSometing()
{
/* do something */
}
});
Imagine you have several abstract methods in one interface/class, which
would need several callbacks passed to the constructor.
Also '$this' is mapped to the right objects.
Regards,
Sebastian
It also avoids usage of these classes outside the scope where they are
defined...
I'm not sure that I like it yet, since the only use cases so far are very
weird edge cases in my strange experiments.
Surely needs stronger use cases first...
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
Re: [PHP-DEV] RFC: Anonymous Classes
On Mon, 23 Sep 2013, Joe Watkins wrote: https://wiki.php.net/rfc/anonymous_classes This RFC misses one very important part: an argument for why this feature is useful. Syntax changes are likely to be extremely contentious and without convincingreasoning *why* we need this, we shouldn't even consider looking at an RFC. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
On 23 September 2013 11:00, Michael Wallner m...@php.net wrote: On 23 September 2013 10:39, Rasmus Lerdorf ras...@lerdorf.com wrote: On 09/22/2013 11:39 PM, Joe Watkins wrote: https://wiki.php.net/rfc/anonymous_classes I'd like to hear thoughts regarding the addition of anonymous classes, patch included. I am having a hard time picturing a real-world use-case for this. It is a widely used pattern in object oriented programming: ... where you code against interfaces (was supposed to follow that words :)) Sorry. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
On 23 September 2013 10:39, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 09/22/2013 11:39 PM, Joe Watkins wrote:
https://wiki.php.net/rfc/anonymous_classes
I'd like to hear thoughts regarding the addition of anonymous
classes, patch included.
I am having a hard time picturing a real-world use-case for this.
It is a widely used pattern in object oriented programming:
$subject-attach(new class implements SplObserver {
function update(SplSubject $s) {
printf(Got update from: %s\n $subject);
}
);
I'd rather go for a `new BaseType` syntax, though:
$subject-attach(new SplObserver() {
function update(SplSubject $s) {
printf(Got update from: %s\n $subject);
}
);
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
2013/9/23 Derick Rethans der...@php.net On Mon, 23 Sep 2013, Joe Watkins wrote: https://wiki.php.net/rfc/anonymous_classes This RFC misses one very important part: an argument for why this feature is useful. Syntax changes are likely to be extremely contentious and without convincingreasoning *why* we need this, we shouldn't even consider looking at an RFC. I use anonymous classes very frequently in Java and in C#, and I would say that they are quite useful. However the examples given in the RFC are really bad ones. Why on earth would you need a constructor for an anonymous class? Anonymous classes are used to implement quickly some interface. Frankly, constructors are not part of any interface. Besides a constructor is totally useless in an anonymous class as it will never be called after the object is created. Let's not rule out this feature yet. It's just a weak RFC, so let's wait for better approaches. Lazare INEPOLOGLOU Ingénieur Logiciel
Re: [PHP-DEV] RFC: Anonymous Classes
Le 23/09/2013 10:39, Rasmus Lerdorf a écrit : On 09/22/2013 11:39 PM, Joe Watkins wrote: https://wiki.php.net/rfc/anonymous_classes I'd like to hear thoughts regarding the addition of anonymous classes, patch included. I am having a hard time picturing a real-world use-case for this. Adding to the other use-cases already explained: it would also definitely be very useful for mocking in tests. We could create on-the-fly implementations for interfaces, avoiding using complex mocking API (PHPUnit or others). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
Hi Joe, what about serialization for those classes? cu, Lars Am 23.09.2013 um 08:39 schrieb Joe Watkins krak...@php.net: Morning All, https://wiki.php.net/rfc/anonymous_classes I'd like to hear thoughts regarding the addition of anonymous classes, patch included. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] RFC: Anonymous Classes
On 09/23/2013 02:43 PM, Lars Strojny wrote: Hi Joe, what about serialization for those classes? cu, Lars Am 23.09.2013 um 08:39 schrieb Joe Watkins krak...@php.net: Morning All, https://wiki.php.net/rfc/anonymous_classes I'd like to hear thoughts regarding the addition of anonymous classes, patch included. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Same as any other object; what you are creating is normal classes without a (declared) name, nothing about the objects functionality has differs from an object of a named class. Cheers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
Am 23.09.2013 16:06 schrieb Joe Watkins krak...@php.net: On 09/23/2013 02:43 PM, Lars Strojny wrote: what about serialization for those classes? Same as any other object; what you are creating is normal classes without a (declared) name, nothing about the objects functionality has differs from an object of a named class. What about UNserialize then? Will you extend the serialized format to include the full definition of the anonymous class, so that it can be reinstated at unserialization time? If not, what will be the class (and baseclass and interfaces) of the unserialized formerly-anonymous objects? best regards Patrick
Re: [PHP-DEV] RFC: Anonymous Classes
2013/9/23 Joe Watkins krak...@php.net On 09/23/2013 02:43 PM, Lars Strojny wrote: Hi Joe, what about serialization for those classes? cu, Lars Am 23.09.2013 um 08:39 schrieb Joe Watkins krak...@php.net: Morning All, https://wiki.php.net/rfc/**anonymous_classeshttps://wiki.php.net/rfc/anonymous_classes I'd like to hear thoughts regarding the addition of anonymous classes, patch included. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Same as any other object; what you are creating is normal classes without a (declared) name, nothing about the objects functionality has differs from an object of a named class. When you serialize an object the serialized form contains the class name. So as long as the instance doesn't have a own class name it isn't possible to serialize it properly and even further to unserialize it, because the whole definition is gone. To sum it up: They aren't serializable. Imo it isn't such a flaw, that anonymous instances aren't serializable, because anonymous functions/closures aren't neither. Regards, Sebastian. Cheers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] RFC: Anonymous Classes
Hi,
On Sep 23, 2013 at 3:05 PM, Joe Watkins krak...@php.net wrote:
On 09/23/2013 02:43 PM, Lars Strojny wrote:
Hi Joe,
what about serialization for those classes?
cu,
Lars
Same as any other object; what you are creating is normal classes without
a (declared) name, nothing about the objects functionality has differs from
an object of a named class.
I think that the question was: How would you figure out method
implementation for unserialized object of anonymous class? Consider this
example...
$o = new class() {
private $a = 1;
public function test() { echo $this-a; }
};
$o-test();
$str = serialize($o);
$o2 = unserialize($str);
$o2-test();
How would this work?
Jakub
RE: [PHP-DEV] RFC: Anonymous Classes
What about UNserialize then? I don't see any way to handle this sensibly, but I also don't regard this as a problem, because that's not what these anonymous classes are for. If you want something that can be unserialised into a thing with methods then logically you know what it is ahead of time, because you know what functionality you want it to have, so you would have a named class for it. If you don't want it to have methods then it's just a value object and stdClass will suffice (you wouldn't have created the anonymous class in the first place). All? the use cases mentioned are centred around interfaces and interfaces don't include values (i.e. properties), which is all that serialisation stores apart from the class name, which by definition doesn't apply to anonymous classes. The opposite of this problem, unserialising anonymous objects into instances of defined classes, would be very useful in many places (especially JSON) but I guess that's another prickly issue for another thread. To summarize how I think this should be handled: Serialisation results in a stdClass, unserialisation cannot be done because if you want it you're already Doing It WrongT. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
On 23 September 2013 08:03, Chris Wright daveran...@php.net wrote: To summarize how I think this should be handled: Serialisation results in a stdClass, unserialisation cannot be done because if you want it you're already Doing It WrongT. To me, serialising successfully would indicate that PHP could unserialise the object as it was. Since it can't, I'd prefer to just error out at the serialize() stage. As for the feature itself, I'm not really sold right now. The use cases I've seen for this previously in other languages have been situations where either a simple anonymous function or closure would suffice, or alternatively situations where you have a big anonymous class with lots of methods, and I think for the latter case I'd rather promote separating those sorts of implementations into standalone classes for readability reasons. Adam, who isn't even pretending that he's looked at the patch yet. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
Hi Joe, Am 23.09.2013 um 19:22 schrieb Joe Watkins krak...@php.net: [...] As I have said, serialization does work, and unserialization does work ... Classes do have unique names, so as long as the entry is present upon unserialize you will get the object you expect ... if the entry is not present unserialization will fail silently. The same kind of thing can happen where you have declared a class based on some predicate, whose value has changed upon unserialize and so the entry is not present ... I'm not sure it is necessary to force any particular behaviour for serialization, it depends entirely on the application whether or not the entry is present upon serialization, it should be left down to the programmer. it would make sense to forbid serializing anonymous classes like we forbid serializing closures. What do you think? cu, Lars signature.asc Description: Message signed with OpenPGP using GPGMail
