RFC: Anonymous Classes

2013/9/23 Rasmus Lerdorf rasmus@lerdorf.com

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

--

--
github.com/KingCrunch

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

2013/9/23 Derick Rethans derick@php.net

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

Hi Joe,

what about serialization for those classes?

cu,
Lars

Am 23.09.2013 um 08:39 schrieb Joe Watkins krakjoe@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

--

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

Everyone,

As a lurker i rarely have anthing to say, but this time i'd like to make an
exception: I see some usability for this type of usage, but would like to
disagree on the extra class...
My usage would be more in line with JSON way of passing around objects...
But i'd hate to see yet another new class type and kind of feel the
StdClass would've been more logical...
The reasons for this imho is that the StdClass is the one-for-all object
without anything that's already there... (it's not like anonymous functions
are something different than regular functions?)

As for actual need: personally i can easily live without, but then again:
we the influx of JSON-like notation / ubiquity this might make a logical
follow up.. ?

Met vriendelijke groet,

Robin Speekenbrink
Kingsquare BV

2013/9/23 Joe Watkins krakjoe@php.net

Morning All,

 https://wiki.php.net/rfc/**anonymous_classes<https://wiki.php.net/rfc/anonymous_classes>

 I'd like to hear thoughts regarding the addition of anonymous

classes, patch included.

Cheers
Joe

Serialization:

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.

Cheers
Joe

Hi Joe,

Am 23.09.2013 um 19:22 schrieb Joe Watkins krakjoe@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

Hi,

Serialization:

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.

sorry if I missed something when I read your patch but the name of the
class is defined as Class$$%lu where %lu is substituted by the current
compiler global variable anon_class_id that is incremented before. This
could lead to the unexpected results when the script that unserialize
objects define anonymous classes in different order than serializing
script. Then you can get completely different definition. In most cases you
would get when you try to use some method that are not defined but you
could also have something like this:

serialize script
<?php
$a = new class() { public $a = 100; public function foo() { echo $a + 1; }
} // class name: Class$$1
$b = new class() { public $a = 0; public function foo() { echo $a - 1; } }
// class name: Class$$2
$str = serialize(array($a, $b)); // str:
a:2:{i:0;O:8:"Class$$1":1:{s:1:"a";i:100;}i:1;O:8:"Class$$2":1:{s:1:"a";i:0;}}
save_str_to_db($str);
$a->foo(); // 101
$b->foo(); // -1

unserialize script
<?php
new class() { public $a; public function foo() { echo $a - 1; } } // class
name: Class$$1
new class() { public $a; public function foo() { echo $a + 1; } } // class
name: Class$$2
$str = load_str_from_db();
list($a,$b) = unserialize($str);
$a->foo(); // 99
$b->foo(); // 1

I know that this just a non-sense example but there could be some more
complex situations that this could happened. You will get different result
just because the classes are defined in different order...

As I said I could miss something but if this is the case I think that the
serialization issue should be addressed in the patch.

Jakub

2013/9/23 Joe Watkins krakjoe@php.net

Morning All,

 https://wiki.php.net/rfc/**anonymous_classes<https://wiki.php.net/rfc/anonymous_classes>

 I'd like to hear thoughts regarding the addition of anonymous

classes, patch included.

Cheers
Joe

Serialization:

As I have said, serialization does work, and unserialization does work
...

Actually if you cant unserialize a "serialized object", it isn't a
serialized object, but only a string describing the object it was created
from.

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.

Which name do you give them? The name of the originating interface/class?

if ($debug) {
$listener = new class extends ListenerInterface () {
public function onFoo() { debug(); };
};
} else {
$listener = new class extends ListenerInterface () {
public function onFoo() { normal(); };
};
}

$someBar->addListener($listener);
$x = serialize($listener);

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.

Cheers
Joe

--

--
github.com/KingCrunch

On 24 September 2013 14:51, Nicolas Grekas nicolas.grekas+php@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;

hi!

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