Everything

php

AW: PDM Meeting Notes

php.internals

Matthias Pigulla

20 years ago

Great, I have been waiting for this list sine Derick mentioned the
meeting in his talk at the conference :)

@Derick: There have been some questions and issues raised during your
talk... Dou you remember them? It was about reading from files with the
new unicode semantics, and you said these were some things you need to
discuss. I don't see anything that looks related... Do you remember what
it was about?

> 2.10 Dynamic class inheritance

Can someone elaborate a little on what this is supposed to be ;)?

> 5.2 Allow interfaces to specify the __construct() signature

> Discussion: We didn't see a reason why this shouldn't be allowed,
> but Andi seems to have a reason for it.
> Conclusions: Zeev asks Andi why he doesn't want constructors in
> the interface. If there is no sound reason we add this
> possibility.

I had a discussion about this with a colleague recently. IMHO specifying
construcor signature does not make sense at all in interfaces... What is
that supposed to do at all? I mean - conceptually, what does it express?

> 5.3 Implement inheritance rules for type hints
> Issue: Currently we don't check inheritance rules for type-hinted
> parameters.

Could someone please explain what exactly is/is not checked?

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

Interesting feature :) I've been missing that on C# recently ;)

As to type hinting, has there ever been a discussion about allowing
string/int/... type hints? These could perform appropriate casts so you
don't need to make such checks at the beginning of every method you
write.

-mp.

Rasmus Lerdorf

20 years ago

Matthias Pigulla wrote:

>> 2.10 Dynamic class inheritance
>
> Can someone elaborate a little on what this is supposed to be ;)?

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.

> I had a discussion about this with a colleague recently. IMHO specifying
> construcor signature does not make sense at all in interfaces... What is
> that supposed to do at all? I mean - conceptually, what does it express?

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.

> As to type hinting, has there ever been a discussion about allowing
> string/int/... type hints? These could perform appropriate casts so you
> don't need to make such checks at the beginning of every method you
> write.

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

-Rasmus

Marcus Börger

20 years ago

Hello Matthias,

Tuesday, November 22, 2005, 9:22:16 PM, you wrote:

>> 2.10 Dynamic class inheritance

> Can someone elaborate a little on what this is supposed to be ;)?

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

>> 5.3 Implement inheritance rules for type hints
>> Issue: Currently we don't check inheritance rules for type-hinted
>> parameters.

> Could someone please explain what exactly is/is not checked?

From a 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

Bob Silva

20 years ago

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

Marcus Börger

20 years ago

Hello Bob,

Wednesday, November 23, 2005, 1:44:53 AM, you wrote:

> 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 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.

> 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.

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

reagrds
marcus