RE: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_compile.c ...
| From: | Dmitry Stogov | Date: | Mon, 06 Mar 2006 09:23:27 +0000 |
| Subject: | RE: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_compile.c ... | ||
| References: | 1 | Groups: | php.zend-engine.cvs |
| Request: | Send a blank email to php-zend-engine-cvs+get-4693@lists.php.net to get a copy of this message | ||
You mean static methods. Right?
Because regular (virtual) methods must be compatible in interface and
sub-interface.
And what was the decision about static methods in nterfaces? I cannot
remember.
(seems they bring the same problem).
Dmitry.
> -----Original Message-----
> From: Marcus Boerger [mailto:helly@php.net]
> Sent: Monday, March 06, 2006 12:08 PM
> To: Dmitry Stogov
> Cc: 'Antony Dovgal'; zend-engine-cvs@lists.php.net
> Subject: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_compile.c ...
>
>
> Hello Dmitry,
>
> that are the same rules as with any other interface method.
> If you think they are not perfect please grab the original
> discussions. Iirc we discussed all this behavior and said
> that it should be impossible to have two methods from two
> different interface. Including the disability to overload an
> inherited method in a derived interface.
>
> marcus
>
> Monday, March 6, 2006, 10:02:04 AM, you wrote:
>
> > What about an interfaces those extends other interface.
> > The following code produces "Fatal error":
>
>
> > <?php
> > interface A {
> > function __construct($a);
> > }
> > interface B extends A {
> > function __construct($a, $b);
> > }
> > class C implements B {
> > function __construct($a,$b) {}
> > }
> ?>>
>
> > Thanks. Dmitry.
>
> >> -----Original Message-----
> >> From: Antony Dovgal [mailto:antony@zend.com]
> >> Sent: Monday, March 06, 2006 11:45 AM
> >> To: Dmitry Stogov
> >> Cc: 'Marcus Boerger'; zend-engine-cvs@lists.php.net
> >> Subject: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 /
> zend_compile.c ...
> >>
> >>
> >> On 06.03.2006 10:33, Dmitry Stogov wrote:
> >> > Marcus,
> >> >
> >> > Don't roll it back.
> >> > I just like make one note.
> >> > If class implements interface with constructor then all its
> >> subclasses
> >> > may not change constructor's prototype. If this is OK for
> >> all, then I
> >> > haven't any other objections to the pacth.
> >>
> >> I'd say this is the whole point.
> >> Interface developer should be able to specify constructor's
> >> prototype (if needed)
> >> and developers implementing this interface should not be able
> >> to change it.
> >>
> >> --
> >> Wbr,
> >> Antony Dovgal
> >>
> >>
>
>
>
>
>
> Best regards,
> Marcus
>
>
>