rasmus@lerdorf.com (rasmus

Also known as runtime inheritance, or late binding. It's not a new
thing, we have it today. The discussion was about whether to have a way
to disable this and force people to define their classes at the
top-level of scripts and to define them in the correct order so all
binding can be done at compile-time which is of course faster. The
conclusion was that this could be done at the opcode cache level.


Just like any other signature in an instance, it tells anything that
implements the interface that it must have a constructor and that
constructor must meet the definition in the interface. Useful for
object factories. In most cases you don't want to force a specific
constructor in which case you wouldn't specify it in the interface, but
I see no reason why you shouldn't be allowed to specify it there if you want to.

Yes, a lot of folks are strongly against going down that route.

-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

mp@webfactory.de (matthias

Ok, that is, having __construct in the interface asserts that everything
you get passed (as an implementation of the interface) has been
constructed by a constructor that has a certain signature? :--/ Of
course it also doesn't make sense to call __construct on the
implementation passed along.

Luckily this is nothing I'm forced to write in my code .

I only wanted to utter I have a Bad Feeling(TM) if you invest time and
effort to make stuff like this work if the result is something that
seems to make no sense [to me only?]. And once you allow it, be sure ppl
out there use & abuse it and will complain should you ever have to
remove it again.

...

I'm just trying to make up a scenario where the above might make sense -
it could be where you have something like a factory method. It has a
type hint on it's argument to make sure what gets passed in implements a
certain interface.

That interface defines the signature of __construct, so the method can
construct instances of the "thing" - only knowing that the instances
constructed will implement the interface (?), but not knowing their
implementation.=20

But how should it construct instances? new INameOfTheInterface()? And
besides that, problem is again that the "thing" passed in would have to
be something representing a class, and not an instance of the class
itself. You could always (gut feeling) re-design this to work "the usual
way" by passing in something representing a class and providing
behaviour to construct instances.

I hope Andi backs me

-mp.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

helly@php.net (marcus

Hello Matthias,


Binding static members at run time rather than compile time. See the notes
for an example that shows the difference. Usage example again factories.

From=20a typesystem point of view it would be perfectly leagal to change the
typehint in a derived class as long as that respects is-a relation with the
parent. Since the explanation is a bit complex, not what most people expect
we live with the simple disagreement. And since most languages do not
respect this correct or not at all anyway there is obviously no real common
usecase for it. So PHP can live without that too (imo).

Best regards,
Marcus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

helly@php.net (marcus

Hello Matthias,


The patch is ready already and actually it is a single line change that was
obvious from the first place. What really causes work here is explaning this
over and over again.

The typical way out is to completley re-design the software once reached
this need or change to reflection to at least prevent from more severe
errors.

Best regards,
Marcus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

me@bobsilva.com (bob

5.4 Late static binding using "this" without "$" (or perhaps with a
different name)

The same example, but now with the call to "self::static2()" replaced with
"static::static2()", will then print "B::static2".


Using static::func() is a bit corny, I understand why you don't want another
new keyword so here is a few more suggestions:

class::func()
default::func()
final::func()

I personally think the class:: would be a better solution than static::,
although this:: is the best solution, can I ask why that was ruled out since
the title of the section indicates it was the first preference.

Thanks

Bob Silva


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

helly@php.net (marcus

Hello Bob,

I don't like default or final here. Default because there is no default
class in php and no such thing as a default class is involved here. Final
not because final has a dedicated semantics already. And that deals with
inheritance and tracks down to something that can be or should be done at
compile time and we want to find a keyword here that describes something
that should be done in run time. Class is nice though.


Preventing confusion between $this and this to keep the code clean and
readable.

reagrds
marcus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

mp@webfactory.de (matthias

....

I also thought about that:

$whichClass =3D ...
if ($whichClass instanceof ISomehowConstructable)
$foo =3D new $whichClass(...);

would even work without reflection, but of coure would require to change
instanceof a little, too - similar to the way is_subclass_of works right
now.=20

-mp.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php