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).
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
