Hello Jochem,
Wednesday, November 23, 2005, 6:52:17 PM, you wrote:
> Christian Schneider wrote:
>> Jochem Maas wrote:
>>
>>> so I can only assume that the ability to declare ctor signatures have
>>> been left in because they do no harm regardless of whether it is
>>> 'correct'.
>>
>>
>> If I remember correctly then one reason to have constructor signatures
>> is for object factories: You specify that an object to be created by a
> using an object factory its quite feasable under certain conditions to
> make the ctor protected to force the use of the factory - the same applies
> to singleton implementations.
> hence I don't that a ctor is by its definition public - although, granted,
> in the normal case it usually so.
>> specific factory has to follow certain constructor rules. I see nothing
>> wrong with that, it is part of a public interface of a class and hence
>> one should be able to specify it in an interface.
>>
>>> abstract static protected function __construct(CrazySettings $s,
>>> CrazyView $v);
>>
>>
>> Abstract is purely redundant here as interfaces never implement a
>> function. If on the other hand you mean that classes _implementing_ this
>> interface have to declare those methods as abstract then I don't see how
>> anyone could actually use this interface as no non-abstract class could
>> implement these functions in the interface.
> right - I merely meant that the 'abstract' keyword was harmless and could
> safely
> be ignored by the engine if used in this context.
>>
>> Static doesn't really make sense as interfaces as object instance related.
> that is a matter of consensus (if the accepted software design paradigms
> change that may very well be considered bullshit in the future) - is there any
> solid technical reason that the ability to declare an interface method as
> static? if not then why change the behaviour? (not to mention that it happened
> in a minor version - going from 'working' to E_FATAL is a rather drastic
> change
> for a minor version upgrade).
>>
>> As far as protected and private go I have less strong of an opinion but
>> I understand the point of view that interfaces describe the _public_
>> interface of an object, everything else are implementation details.
> I understand the point of view as well, I understand it very well thanks.
> but I'd like to throw back an argument often used by core developers:
> 'if you don't like it you don't have to use it'
> So rather than forcing me to change my previously working code just don't used
> protected/private/static in _your_ interface declarations. and if you ('you'
> in general!)
> really really must impose such purism then either impose it from the start
> (shitty
> argument I realise!) or at least let me determine _when_ I fix my code
> (rather than being _forced_ to stay late at work and not be able to see my
> son -
> which has happened to be my reality with respect to abitrary changes
> in php on more than one occasion) byt giving me an E_STRICT rather than an
> E_FATAL,
> an E_FATAL I have to fix otherwise i lose my client, with an E_STRICT I can
> go home
> and worry about it tomorrow.
> AND BESIDES: there is is nothing in the word 'interface' that implies the
> concept
> of public - going back to your own factory example - its very handy to be
> able to
> allow the the actual factory to conditionally call (or trigger the calls to)
> certain methods on the objects its generating/creating that are only relevant
> to the
> setup/init of said objects - imho the neatest way is to use interfaces, and
> the neatest
> way to stop anyone from using the relevant method once the object has been
> created and returned
> to the callee is to make it protected (this assumes, in the simplest case,
> that the factory
> is also the base class for all the classes of the objects it produces - which
> is not an
> impossibility).
Whike speaking of private or protected interface functions everyone here
seems to do the same wrong assumptions. Regarding private the problem is
that provate members are not visible outside of a scope. Hence a class
that implements an interface with a private method will always have on
abstract function. So Neither the class itself nor any of its child can
be instanciated. The only usage left is to have a way to introduce static
classes. But luckily we are not Java and hava use for that. And even if
we had we could do it with "static class ... { ... }". Now coming to
protected members in interfaces the problem is that it is always possible
to increase visibility in derived classes. Thus protected in interfaces
doesn't give you anything because we have no compile time function call
generation for interface based invocation. Actually in PHP none of the
last two sentences makes any sense whatsoever.
What you might want to enforce here ist that having a visibility
declaration makes it impossible to change a functions visibility thus
you suddenly make the visibility part of the inherited signature of a
function. Doing so would make PHP code suddenly much harder to devlop
because it would be very hard to see why the behavior of basic rules
suddenly changes.
Allowing ctors in interfaces simply reinforces a rule we disabled
especially for ctors. Thus all normal rules apply and nothing new has
to be learned. Which is imo even easier then what we have toay where
you have to learn that interfaces *do not* allow to enforce signatures
on ctors.
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
