Re: AW: AW: [PHP-DEV] PDM Meeting Notes

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