why does the engine care about the visibility of interface methods I declare?
I understand the argument that interface methods only have 'meaning' when
applied
as public methods of objects - but thats rather academic and personally I can
think of useful ways to abuse interfaces using protected methods at the very
least
why am I not allowed to do this just because someone decided that its not
correct?

and given that I can implement a non-static method without using $this or any
other symbol/code
related to the instantiated object (effectively creating a static method) which
I can
call using static notation why not allow static interface methods?

also I noticed that using the keyword 'abstract' with a interface method
declaration
is all of a sudden (5.1RC5dev) causing a fatal error where before (5.0.2 -
5.0.4)
no error what so ever.

If 'static', 'protected', 'private' are not allowed with interfaces (very
unpragmatic imho)
then why the fatal errors? why not an E_STRICT and just ignore those
declaration... especially
because not declaring a method static and leaving off the visibility leaves you
with a
method that is non-static and public - exactly what an interface 'requires'.

rgds,
Jochem

----

some might ask why I am asking - well the motive is quite simple:

"I try to stay on top of php developments, trying out to the best of my
abilities new features whenever I see an opportunity. partly for fun,
partly
to be able to encourage/help others to step up to the php5 plate.
lately I
_feel_ I am being punished more and more for trying to keep abreast
due to BC breaks
(some of which, I realise, are very much required) and more annoyingly
abitrary
changes in behaviour."

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

> why does the engine care about the visibility of interface
> methods I declare?
> I understand the argument that interface methods only have
> 'meaning' when applied as public methods of objects - but
> thats rather academic and personally I can think of useful
> ways to abuse interfaces using protected methods at the very
> least why am I not allowed to do this just because someone
> decided that its not correct?

Having anything else than "public" in an interface simply does not make
any sense - an interface serves as a contract to external clients. It
guarantees them that there will be a set of methods they can call on an
object instance. What should be the semantic meaning of non-public
elements in interfaces?

> and given that I can implement a non-static method without
> using $this or any other symbol/code related to the
> instantiated object (effectively creating a static method)
> which I can call using static notation why not allow static
> interface methods?

As to static interface methods - same as above. An interface is an
interface :), not an implementation. So you will never have methods
implemented in an interface. The interface just says "the class
implementing the interface has a method named xy() that you can call".

So how would you make the static call on the interface?
ISomewhat::someMethod()? Where should that be implemented? This is why
you always need an instance that implements the interface and you make a
"normal" call on this instance. PHP allows - as opposed to C# or Java
(IIRC) - to call static methods on instances.

I think the fact that you can call nonstatic methods statically is BC
with "early days"; you don't want to do that in your code because it
will get you problems sooner or later. In "older" code you could not
mark methods as static, so the language could not check if a static call
is allowed. It simply permitted the call, not setting $this.

> also I noticed that using the keyword 'abstract' with a
> interface method declaration is all of a sudden (5.1RC5dev)
> causing a fatal error where before (5.0.2 - 5.0.4) no error
> what so ever.

I thought I would never write anything like that - but: What sense does
"abstract" make in an interface at all?

You shouldn't have been writing "abstract" in an interface in the first
place. >:)

> If 'static', 'protected', 'private' are not allowed with
> interfaces (very unpragmatic imho) then why the fatal errors?
> why not an E_STRICT and just ignore those declaration...

As I understand it, E_STRICT is for complaining about stuff like "var"
that was ok with PHP4 but is discouraged in PHP5. But you are using PHP5
elements in a way that make no sense to the language, so it's simply an
error.

> especially because not declaring a method static and leaving
> off the visibility leaves you with a method that is
> non-static and public - exactly what an interface 'requires'.

You're explicitly requesting something that is not possible - an fatal
error is the only thing that can be the result.

Matthias

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

Matthias Pigulla wrote:why does the engine care about the visibility of interfacemethods I declare?I understand the argument that interface methods only have'meaning' when applied as public methods of objects - butthats rather academic and personally I can think of usefulways to abuse interfaces using protected methods at the veryleast why am I not allowed to do this just because someonedecided that its not correct?Having anything else than "public" in an interface simply does not make
any sense - an interface serves as a contract to external clients. It
guarantees them that there will be a set of methods they can call on an
object instance. What should be the semantic meaning of non-public
elements in interfaces?thats not my problem though is it - and I did mention that I already understand
what you you are now repeating.

I had a good reason to create an interface whose
methods were only relevant to the innards of a particular (rather large for my
doing)
class hierarchy - I don't give a rats ass as to what you think the 'semantic
meaning'
of that should be - it worked in the 5.0RC1, I understood what I was doing and
I was happy doing it. I certainly was not forcing you to do it too, so why
force me to rewrite/hack my code (sometimes you devs have to do this because I
abuse
things like array_pop() ;-) but I don't feel that this is the case here at all).and given that I can implement a non-static method withoutusing $this or any other symbol/code related to theinstantiated object (effectively creating a static method)which I can call using static notation why not allow staticinterface methods?As to static interface methods - same as above. An interface is an
interface :), not an implementation. So you will never have methods
implemented in an interface. The interface just says "the class
implementing the interface has a method named xy() that you can call".

So how would you make the static call on the interface?
ISomewhat::someMethod()? Where should that be implemented? This is why
you always need an instance that implements the interface and you make a
"normal" call on this instance. PHP allows - as opposed to C# or Java
(IIRC) - to call static methods on instances.right which meant in one particular case I had to create an object especially
to call the given method, very wasteful, pointless and the only good reason
there
seems to be is some academic crud which you have reiterated here.I think the fact that you can call nonstatic methods statically is BC
with "early days"; you don't want to do that in your code because it
will get you problems sooner or later. In "older" code you could not
mark methods as static, so the language could not check if a static call
is allowed. It simply permitted the call, not setting $this.everything I mention here is related only to my experience
with php5 and up since Nov'03.also I noticed that using the keyword 'abstract' with ainterface method declaration is all of a sudden (5.1RC5dev)causing a fatal error where before (5.0.2 - 5.0.4) no errorwhat so ever.I thought I would never write anything like that - but: What sense does
"abstract" make in an interface at all?the point is it doesn't hurt _you_ to let _me_ do it. if it makes sense to
me but nobody else thats no reason not to allow it on grounds of principle
when it is clear that it has worked without problem.You shouldn't have been writing "abstract" in an interface in the first
place. >:)thank you very much - how enlightening. the engine can safely ignore the
'abstract' regardless at that point. no E_FATAL required.

besides semantically an interface is abstract as are the method declarations in
it,
I am not allowed mark a method in an interface as 'abstract' but I'm not allowed
to give it a body either - notice a slight discrepancy?

or are you saying that the 'abstract' keyword in the declaration of an
interface method opens the doors for painful/impossible to debug
segfaults? if so I'll retract my opinion.If 'static', 'protected', 'private' are not allowed withinterfaces (very unpragmatic imho) then why the fatal errors?why not an E_STRICT and just ignore those declaration...As I understand it, E_STRICT is for complaining about stuff like "var"
that was ok with PHP4 but is discouraged in PHP5. But you are using PHP5
elements in a way that make no sense to the language, so it's simply an
error.and as I understand it E_STRICT is for pedantic checking - i.e. check if every t
is crossed and every i dotted (so to speak) nothing perse to do with
php4 (or will E_STRICT be dropped when support for php4 code is dropped from
the engine?)

anyway that was merely a suggestion - basically the E_FATAL is bogus imho.especially because not declaring a method static and leavingoff the visibility leaves you with a method that isnon-static and public - exactly what an interface 'requires'.You're explicitly requesting something that is not possible - an fatal
error is the only thing that can be the result.if its not possible then I what flippin' universe have I been coding in
for the past 2 years??? the only thing making it 'not possible' is
self-imposed purism.Matthias--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Please read the archives where discussions took place.
As you stated it would be "abusing" the notion of what interfaces are.
Take a look at abstract classes. That might help you.

Andi

At 07:24 AM 11/16/2005, Jochem Maas wrote:why does the engine care about the visibility of interface methods I declare?I understand the argument that interface methods only have 'meaning'when appliedas public methods of objects - but thats rather academic and personally I canthink of useful ways to abuse interfaces using protected methods atthe very leastwhy am I not allowed to do this just because someone decided thatits not correct?and given that I can implement a non-static method without using$this or any other symbol/coderelated to the instantiated object (effectively creating a staticmethod) which I cancall using static notation why not allow static interface methods?also I noticed that using the keyword 'abstract' with a interfacemethod declarationis all of a sudden (5.1RC5dev) causing a fatal error where before(5.0.2 - 5.0.4)no error what so ever.If 'static', 'protected', 'private' are not allowed with interfaces(very unpragmatic imho)then why the fatal errors? why not an E_STRICT and just ignore thosedeclaration... especiallybecause not declaring a method static and leaving off the visibilityleaves you with amethod that is non-static and public - exactly what an interface 'requires'.

rgds,
Jochem

----

some might ask why I am asking - well the motive is quite simple:"I try to stay on top of php developments, trying out tothe best of myabilities new features whenever I see an opportunity.partly for fun, partlyto be able to encourage/help others to step up to the php5plate. lately I_feel_ I am being punished more and more for trying to keepabreast due to BC breaks(some of which, I realise, are very much required) and moreannoyingly abitrarychanges in behaviour."

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

Andi Gutmans wrote:Please read the archives where discussions took place.
As you stated it would be "abusing" the notion of what interfaces arTake a look at abstract classes. That might help you.Andi,

I read pretty much everything but the account requests on internals
(and have done since php5 was in beta), I am aware of the discussion you
refer to and I understand the logic regard how interfaces should be used
(i.e. what they were made for, at the very least in the eyes of those who
made them in this case).

I put 'abuse' in quotes because there is no one definitive answer to software
design - and my experience is people disagree wildly on what is right and wrong.

my complaint is that alot of the 'small' changes that have been happening
lately that are sold as improvements with regard to better software design,
improved development feedback (in order to catch bugs before they bit you, etc)
but they don't always stand up to the sales pitch IMO.

stating 'abstract' shouldn't be set on a method declared in an interface
definition
is one thing but making it a fatal error to do so is another - baring in mind
the
context that it used to work, and as far as I can see does no harm (i.e. the
engine
can just ignore it). the E_FATAL forces the coder to the change the code on the
spot
... an E_STRICT would give the coder a hint on how to write better/correct code
but
does not force him to do something about it.

another example is array_merge() whose behaviour is now inconsistent with
how one can use an array or null interchangably elsewhere.

more worrying is the seemingly very real posibility that php functions will
soon be auto casting their arguments in a different way to explicit casting
(and auto-casting within expressions?). I have spent alot of time studying and
learning
how the casting works in php (100,000's of people can probably say the same)
- all that is put in jeopardy for the sake of some purist dream...
whether "123abc" shouldn't cast to integer "123" or whether is should doesn't
interested
me - the fact that it does I consider a plus point, php's autocasting rocks -
what I do find important is that it keeps working as it does.

I have given a couple of examples of break/changes that I feel are
counter-productive,
goes against the practical/pragmatic ideal that php (I believe) was built upon,
and possibly
most importantly alienate (lesser) coders and damages php's reputation.

The whole situation is compounded by the fact that quite severe (in
terms of
affect on php users) changes _had_ to be made to the engine recently that
caused BC break
related to references. which is a case where there was a very strong argument
(the only
critism might be that the argument was not conveyed to php userland strongly
enough).
At any rate php has had to undergo some changes that really were required and
it was a bitter
pill for most (Derick R. I recall spent alot of time getting his EZsystem to
work with the
fixed reference stuff.), from a marketing perspective following a necessary
bitter pill
with a stack of bitter pills that are not strictly necessary in quick sucession
is
bad tactics.

so my whole gripe lies in the arena of consistently and the aparently increasing
lean toward purism for its own sake (which to me is not the same as improving or
fixing something because it really needs/deserves it) rather than towards what
may or
may not be the academically correct implementation of a feature. or are we
witnessing
php's slow but sure departure from its roots in order to preen it for
enterprise use,
leaving its major userbase stuck with php4 and looking for a new home?

thanks very much for your time,
rgds,
Jochem

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

An interface is a public contract that describes the behaviour of an object.
If you're not using interfaces in that way, you're doing something
fundamentally wrong.

--Wez

On 11/16/05, Jochem Maas <> wrote:
> why does the engine care about the visibility of interface methods I declare?
> I understand the argument that interface methods only have 'meaning' when
> applied
> as public methods of objects - but thats rather academic and personally I can
> think of useful ways to abuse interfaces using protected methods at the very
> least
> why am I not allowed to do this just because someone decided that its not
> correct?
>
> and given that I can implement a non-static method without using $this or any
> other symbol/code
> related to the instantiated object (effectively creating a static method)
> which I can
> call using static notation why not allow static interface methods?
>
> also I noticed that using the keyword 'abstract' with a interface method
> declaration
> is all of a sudden (5.1RC5dev) causing a fatal error where before (5.0.2 -
> 5.0.4)
> no error what so ever.
>
> If 'static', 'protected', 'private' are not allowed with interfaces (very
> unpragmatic imho)
> then why the fatal errors? why not an E_STRICT and just ignore those
> declaration... especially
> because not declaring a method static and leaving off the visibility leaves
> you with a
> method that is non-static and public - exactly what an interface 'requires'.
>
> rgds,
> Jochem
>
> ----
>
> some might ask why I am asking - well the motive is quite simple:
>
> "I try to stay on top of php developments, trying out to the best of
> my
> abilities new features whenever I see an opportunity. partly for
> fun, partly
> to be able to encourage/help others to step up to the php5 plate.
> lately I
> _feel_ I am being punished more and more for trying to keep abreast
> due to BC breaks
> (some of which, I realise, are very much required) and more
> annoyingly abitrary
> changes in behaviour."
>
> --
> 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

Jochem,

the point with most of these issues is that there's no common
understanding of what things like protected or static interface members
mean; from an OO point of view, they make no sense, and I was only
trying to explain why.

Unless there is a common understanding what a certain language construct
means, every way of implementing it is pretty arbitrary. So not
implementing it at all is not "self-imposed purism".

> should be - it worked in the 5.0RC1, I understood what I was
> doing and I was happy doing it.

If these things were legal with 5.0.0 (were they really? I dunno...),
one could argue wheter it's good practise to 'suddenly' make them
E_FATAL in a minor release. However, even if they ever worked, at best
it was undocumented (=random) behaviour.

> right which meant in one particular case I had to create an
> object especially to call the given method, very wasteful,
> pointless and the only good reason there seems to be is some
> academic crud which you have reiterated here.

I don't get that should have worked otherwise, but if you want to let's
discuss this one off-list.

> > In "older" code you could not
> > mark methods as static, so the language could not check if a static
> > call is allowed. It simply permitted the call, not setting $this.
>
> everything I mention here is related only to my experience
> with php5 and up since Nov'03.

If a method does not access "$this", it can be used statically. So best
would be to have the "static" modifier in place to make things clear,
but that would require _you_ to add it to your pre-php5 'legacy' code.

So, although "academically" not correct, the engine still permits it -
simply because it did so in the past in an agreed-on manner. With
E_STRICT it will addidionally tell you that as of PHP5 you have a
keyword to get it "right".

> >>also I noticed that using the keyword 'abstract' with a
> >>interface method declaration is all of a sudden (5.1RC5dev)
> >>causing a fatal error where before (5.0.2 - 5.0.4) no error
> >>what so ever.
> >
> > I thought I would never write anything like that - but: What sense
> > does "abstract" make in an interface at all?
>
> the point is it doesn't hurt _you_ to let _me_ do it. if it
> makes sense to me but nobody else thats no reason not to
> allow it on grounds of principle when it is clear that it has
> worked without problem.

"Worked without problem" is not necessarily a good argument for such
things.

However, I just found that "abstract" was also once legal in Java
(http://java.sun.com/docs/books/tutorial/java/interpack/interfaceDef.html, note at the bottom). They removed it because it makes no sense
(interfaces are abstract by nature).

Now I know that this is by no means a better argument ;), but maybe a
notice instead of fatal would be enough?

> > As I understand it, E_STRICT is for complaining about stuff
> > like "var"
> > that was ok with PHP4 but is discouraged in PHP5. But you are using
> > PHP5 elements in a way that make no sense to the language, so it's
> > simply an error.
>
> and as I understand it E_STRICT is for pedantic checking -
> i.e. check if every t is crossed and every i dotted (so to
> speak) nothing perse to do with php4 (or will E_STRICT be
> dropped when support for php4 code is dropped from the engine?)

I am not really familiar with engine internals, so maybe someone more
enlighted than me could comment on this one and decide if E_NOTICE or
E_STRICT is more appropriate.

> if its not possible then I what flippin' universe have I been
> coding in for the past 2 years??? the only thing making it
> 'not possible' is self-imposed purism.

As you can see I changed my opinion as to "abstract". But as to
non-public and static members - you're asking for the engine to simply
ignore modifiers you explicitly give and that make no sense. Programming
languages don't work that way.

-- mp.

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