Hi
2011/9/23 Ferenc Kovacs :
> A little bit off-topic, but maybe we could also discuss/fix this:
> https://bugs.php.net/bug.php?id=43200
> http://groups.google.com/group/symfony-devs/browse_thread/thread/3fc16ba601045551
I don't see the bug in that matter, because the interface defines the
protot
On Tue, Sep 20, 2011 at 9:35 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/20/11 12:07 PM, Reindl Harald wrote:
>>
>> but it is not logical
>>
>> foo() in B can do anything with $a before or after parent::foo()
>> and the caller does not need to know at any point that B
>> has anything to do with the cl
Hi!
On 9/20/11 12:07 PM, Reindl Harald wrote:
but it is not logical
foo() in B can do anything with $a before or after parent::foo()
and the caller does not need to know at any point that B
has anything to do with the class A
Consider this code:
function doFoo(A $a) {
$a->foo();
}
It's fi
but it is not logical
foo() in B can do anything with $a before or after parent::foo()
and the caller does not need to know at any point that B
has anything to do with the class A
Am 20.09.2011 19:40, schrieb Stas Malyshev:Hi!
On 9/19/11 2:32 AM, Gustavo Lopes wrote:
> The thing if you introduce
Hi!
On 9/19/11 8:34 AM, Etienne Kneuss wrote:
Sure, you can do it. But if you do, you're lying about the
interface. You're telling the callers that you expect no arguments,
but then all of a sudden you error out.
Well, we have no way of declaring that we accept an undefined number of
argu
Hi!
On 9/19/11 7:26 AM, Anthony Ferrara wrote:
that point, why even bother with interfaces? The interface defines
what should be accepted, and any method that implements it should
accept exactly that (no more, no less, no different). Otherwise
Here you lost me. Why exactly you can not accept
Hi!
On 9/19/11 3:20 AM, Pierre Joye wrote:
If we talk about implementing the abstract concept and we use the
interface model to do it, then we do it wrong. I'm out of other
arguments, or maybe one new one, if we implement abstract like
interface, then let kill abstract support, we don't need tha
Hi!
On 9/19/11 2:50 AM, Gustavo Lopes wrote:
* It had to be case that the parameters you want to ignore are the last
Of course, but that's a very common scenario - important parameters go
first, unimportant go last. Or, if I wanted, I could just have blank
signature foo() and figure it out i
Hi!
On 9/19/11 2:32 AM, Gustavo Lopes wrote:
The thing if you introduce func_get_args() to the argument, any discussion
about enforcing signatures becomes meaningless. One could argue this
should be allowed:
class A {
function foo() {}
}
class B extends A {
function foo($a) {}
}
No, this can
On Sep 20, 2011 2:10 AM, wrote:
>
> Hi!
>
> I followed the whole discussion, still it is not clear which one is
> considered good and which bad practice...
>
> In ZF 1 and 2, ZendRegistry::__construct() has the following signature
with
> 2 parameters:
>
> function __construct($array = array(), $fl
Hi!
I followed the whole discussion, still it is not clear which one is
considered good and which bad practice...
In ZF 1 and 2, ZendRegistry::__construct() has the following signature with
2 parameters:
function __construct($array = array(), $flags = parent::ARRAY_AS_PROPS)
while SPL ArrayObje
First of all, Anthony, thanks for joining into the discussion!
>> With respect to the func_get_args argument, I see that as a non-issue.
>> Sure, you can do it. But if you do, you're lying about the
>> interface. You're telling the callers that you expect no arguments,
>> but then all of a sudd
Hi,
On Mon, Sep 19, 2011 at 16:26, Anthony Ferrara wrote:
> Hello all,
>
> I purposely tried to stay out of this conversation, but seeing as
> there's a lot of information flying around I think I'll give my
> $0.02...
>
> As far as the Square-Rectangle example, that is a classic violation of
> t
Hello all,
I purposely tried to stay out of this conversation, but seeing as
there's a lot of information flying around I think I'll give my
$0.02...
As far as the Square-Rectangle example, that is a classic violation of
the LSP. In fact, it's unsolvable using inheritance. For information
as to
2011/9/19 Etienne Kneuss :
> Hi,
>
> On Mon, Sep 19, 2011 at 12:40, Etienne Kneuss wrote:
>
>> Hi,
>>
>> On Mon, Sep 19, 2011 at 12:18, Gustavo Lopes wrote:
>>
>>> Em Mon, 19 Sep 2011 10:56:03 +0100, Etienne Kneuss
>>> escreveu:
>>>
>>>
>>>
Apparently you guys are speaking about the initial
Hi,
On Mon, Sep 19, 2011 at 12:40, Etienne Kneuss wrote:
> Hi,
>
> On Mon, Sep 19, 2011 at 12:18, Gustavo Lopes wrote:
>
>> Em Mon, 19 Sep 2011 10:56:03 +0100, Etienne Kneuss
>> escreveu:
>>
>>
>>
>>> Apparently you guys are speaking about the initial implementation of an
>>> abstract method, w
Hi,
On Mon, Sep 19, 2011 at 12:18, Gustavo Lopes wrote:
> Em Mon, 19 Sep 2011 10:56:03 +0100, Etienne Kneuss
> escreveu:
>
>
>
>> Apparently you guys are speaking about the initial implementation of an
>> abstract method, while I was talking about overriding a method, which is
>> not the relly
Em Mon, 19 Sep 2011 11:20:56 +0100, Pierre Joye
escreveu:
On Mon, Sep 19, 2011 at 12:18 PM, Gustavo Lopes
wrote:
http://www.google.com/codesearch#HmA4mAI_aLc/src/main/java/terrastore/server/impl/support/JsonBucketsProvider.java&q=implements%5C%20MessageBodyWriter&type=cs&l=36
This is the
On Mon, Sep 19, 2011 at 11:50, Gustavo Lopes wrote:
> Em Mon, 19 Sep 2011 10:18:50 +0100, Stas Malyshev
> escreveu:
>
> On 9/19/11 2:12 AM, Gustavo Lopes wrote:
>>
>>> Arbitrary as it may be, it's nevertheless reasonably arbitrated given how
>>> little useful it is to just ignore arguments and
On Mon, Sep 19, 2011 at 12:20 PM, Pierre Joye wrote:
> On Mon, Sep 19, 2011 at 12:18 PM, Gustavo Lopes
> wrote:
> http://www.google.com/codesearch#HmA4mAI_aLc/src/main/java/terrastore/server/impl/support/JsonBucketsProvider.java&q=implements%5C%20MessageBodyWriter&type=cs&l=36
>>
>> This is the
On Mon, Sep 19, 2011 at 12:18 PM, Gustavo Lopes wrote:
http://www.google.com/codesearch#HmA4mAI_aLc/src/main/java/terrastore/server/impl/support/JsonBucketsProvider.java&q=implements%5C%20MessageBodyWriter&type=cs&l=36
>
> This is the most common scenario for implementations of this interface (see
Em Mon, 19 Sep 2011 10:56:03 +0100, Etienne Kneuss
escreveu:
Apparently you guys are speaking about the initial implementation of an
abstract method, while I was talking about overriding a method, which is
not the relly same. So the above doesn't really apply.
The initial implementation
Hi,
2011/9/19 Frédéric Hardy
> Hi !
>
>
>> You misunderstand what LSP means. It does not mean "overriding methods
>> should have same signatures", it means "overriding methods should accept any
>> data that base method accepts". It never says it can not accept any other
>> data.
>>
> Idem.
> So
Hi !
You misunderstand what LSP means. It does not mean "overriding methods
should have same signatures", it means "overriding methods should
accept any data that base method accepts". It never says it can not
accept any other data.
Idem.
So you can have :
class A { public function f($a) {
On Mon, Sep 19, 2011 at 11:55 AM, Gustavo Lopes wrote:
> Em Mon, 19 Sep 2011 10:35:47 +0100, Ferenc Kovacs
> escreveu:
>
>> could you check my second(lengthy) mail on this thread?
>> I also tried to come up with the valid, and invalid signature changes.
>> I forget to take references into account
On Mon, Sep 19, 2011 at 11:56 AM, Etienne Kneuss wrote:
>> There is a precondition that the abstract method enforces in such
>> prototypes, and it is:
>> - I will require at least X arguments
>> if a method implements this and defines the prototype with:
>> - I will require at least Y arguments w
Hi,
On Mon, Sep 19, 2011 at 11:28, Etienne Kneuss wrote:
> Hi,
>
> On Mon, Sep 19, 2011 at 11:19, Pierre Joye wrote:
>
>> On Mon, Sep 19, 2011 at 11:12 AM, Stas Malyshev
>> wrote:
>> > Hi!
>> >
>> > On 9/19/11 2:02 AM, Pierre Joye wrote:
>> >>
>> >> Sorry but your constantly rejecting any logi
On 19 September 2011 10:17, Etienne Kneuss wrote:
> Hi,
>
> 2011/9/19 Frédéric Hardy
>
>> Hi !
>>
>> What is the utility of abstract method if implementation can not follow
>> the signature (constraints ?) of the abstract method ?
>>
> In this case, abstract methods are totaly useless !
>> Moreov
On Mon, Sep 19, 2011 at 11:32 AM, Gustavo Lopes wrote:
> Em Mon, 19 Sep 2011 10:18:50 +0100, Stas Malyshev
> escreveu:
>
>> On 9/19/11 2:12 AM, Gustavo Lopes wrote:
>>>
>>> Arbitrary as it may be, it's nevertheless reasonably arbitrated given how
>>> little useful it is to just ignore arguments a
Em Mon, 19 Sep 2011 10:18:50 +0100, Stas Malyshev
escreveu:
On 9/19/11 2:12 AM, Gustavo Lopes wrote:
Arbitrary as it may be, it's nevertheless reasonably arbitrated given
how little useful it is to just ignore arguments and how likely it is
to a
mistake.
It is not little useful and it is
On Mon, Sep 19, 2011 at 10:40 AM, Gustavo Lopes wrote:
> Em Sun, 18 Sep 2011 20:06:31 +0100, Stas Malyshev
> escreveu:
>
>> On 9/18/11 11:23 AM, Nikita Popov wrote:
>>>
>>> to tell you: I need this and that method accepting these and these
>>> arguments to work correctly. If the signature isn't e
Em Mon, 19 Sep 2011 10:18:50 +0100, Stas Malyshev
escreveu:
On 9/19/11 2:12 AM, Gustavo Lopes wrote:
Arbitrary as it may be, it's nevertheless reasonably arbitrated given
how little useful it is to just ignore arguments and how likely it is
to a
mistake.
It is not little useful and it is
On Mon, Sep 19, 2011 at 11:12 AM, Gustavo Lopes wrote:
> Em Mon, 19 Sep 2011 10:01:32 +0100, Etienne Kneuss
> escreveu:
>
>> Sure, but you mix two things here, references would have to be handled
>> specifically, and we would not allow to specify less args by ref.
>>
>> There is simply no reason
Hi,
On Mon, Sep 19, 2011 at 11:19, Pierre Joye wrote:
> On Mon, Sep 19, 2011 at 11:12 AM, Stas Malyshev
> wrote:
> > Hi!
> >
> > On 9/19/11 2:02 AM, Pierre Joye wrote:
> >>
> >> Sorry but your constantly rejecting any logical, documented, known
> >> principles for the abstract concept is killin
On Mon, Sep 19, 2011 at 11:12 AM, Stas Malyshev wrote:
> Hi!
>
> On 9/19/11 2:02 AM, Pierre Joye wrote:
>>
>> Sorry but your constantly rejecting any logical, documented, known
>> principles for the abstract concept is killing me.
>
> I didn't see any documented principle that say the code I cited
Hi!
On 9/19/11 2:12 AM, Gustavo Lopes wrote:
Arbitrary as it may be, it's nevertheless reasonably arbitrated given how
little useful it is to just ignore arguments and how likely it is to a
mistake.
It is not little useful and it is not likely to make such mistake
without immediately being no
Hi,
2011/9/19 Frédéric Hardy
> Hi !
>
> What is the utility of abstract method if implementation can not follow
> the signature (constraints ?) of the abstract method ?
>
In this case, abstract methods are totaly useless !
> Moreover, i think that it's not compatible with Liskov substitution
> p
Hi!
On 9/19/11 2:05 AM, Frédéric Hardy wrote:
What is the utility of abstract method if implementation can not follow
the signature (constraints ?) of the abstract method ?
In this case, abstract methods are totaly useless !
Moreover, i think that it's not compatible with Liskov substitution
pri
Hi !
What is the utility of abstract method if implementation can not follow
the signature (constraints ?) of the abstract method ?
In this case, abstract methods are totaly useless !
Moreover, i think that it's not compatible with Liskov substitution
principle.
Best regards,
Fred
--
==
Em Mon, 19 Sep 2011 10:01:32 +0100, Etienne Kneuss
escreveu:
Sure, but you mix two things here, references would have to be handled
specifically, and we would not allow to specify less args by ref.
There is simply no reason for disallowing this with nornal args though.
Imagine the following
Hi!
On 9/19/11 2:02 AM, Pierre Joye wrote:
Sorry but your constantly rejecting any logical, documented, known
principles for the abstract concept is killing me.
I didn't see any documented principle that say the code I cited is
prohibited. Only example you brought so far is C function declara
Hi !
What is the utility of abstract method if implementation can not follow
the signature (constraints ?) of the abstract method ?
In this case, abstract methods are totaly useless !
Moreover, i think that it's not compatible with Liskov substitution
principle (http://en.wikipedia.org/wiki/Li
Hi!
On 9/19/11 1:40 AM, Gustavo Lopes wrote:
If the subclass method specifies less parameters, it is very likely a
mistake. It's not usual (certainly it's not more frequent than a mistake
Why would it always be? I had code where overriding class had methods
that need less arguments and substi
On Mon, Sep 19, 2011 at 10:46 AM, Stas Malyshev wrote:
> Please do not assume I disagree with you because I am unable to understand
> you. I understand you perfectly well and you are wrong.
Sorry but your constantly rejecting any logical, documented, known
principles for the abstract concept is
Hi,
On Mon, Sep 19, 2011 at 10:40, Gustavo Lopes wrote:
> Em Sun, 18 Sep 2011 20:06:31 +0100, Stas Malyshev
> escreveu:
>
> On 9/18/11 11:23 AM, Nikita Popov wrote:
>>
>>> to tell you: I need this and that method accepting these and these
>>> arguments to work correctly. If the signature isn't
Hi!
On 9/19/11 1:33 AM, Pierre Joye wrote:
It is the same in C. A class extending an abstract class (or method)
does not extend it per se but implement it. Just like the foo(int a,
float b); is the declaration (abstract) and foo(int a, float b) {
return a * b;= the extended class. This is the ba
Em Sun, 18 Sep 2011 20:06:31 +0100, Stas Malyshev
escreveu:
On 9/18/11 11:23 AM, Nikita Popov wrote:
to tell you: I need this and that method accepting these and these
arguments to work correctly. If the signature isn't enforced, this
doesn't make sense anymore. You could just as well drop t
On Mon, Sep 19, 2011 at 3:00 AM, Stas Malyshev wrote:
> Hi!
>
> On 9/18/11 5:42 PM, Pierre Joye wrote:
>>
>> But this exact example works, only the similar case using abstract
>> will fail, and it makes to fail here as an abstract method is only the
>
> It produces E_STRICT for regular functions,
Am 19.09.2011 03:00, schrieb Stas Malyshev:
> The example without abstract works, but produces E_STRICT which is useless too
right - because the following code is totally valid and reasonable even if
"my_function" will later get a fourth param $d='default' and the strict warnings
here forcing y
Hi!
On 9/18/11 5:42 PM, Pierre Joye wrote:
But this exact example works, only the similar case using abstract
will fail, and it makes to fail here as an abstract method is only the
It produces E_STRICT for regular functions, but for some reason not for
ctors, but fatal error for abstract ctor
On Mon, Sep 19, 2011 at 2:42 AM, Pierre Joye wrote:
> But this exact example works, only the similar case using abstract
> will fail, and it makes to fail here as an abstract method is only the
> declaration, the implementation being done in the child class (bar
> extends foo). This is the concep
On Mon, Sep 19, 2011 at 2:27 AM, Stas Malyshev wrote:
> Hi!
>
> On 9/18/11 5:24 PM, Pierre Joye wrote:
>>
>> class foo{
>> function __construct(){}
>> }
>> class bar extends foo{
>> function__construct($a, $b){}
>> }
>
> Come on. This is not my example. My example was:
>
> class foo{
> functio
On Mon, Sep 19, 2011 at 2:24 AM, Pierre Joye wrote:
> On Mon, Sep 19, 2011 at 1:59 AM, Stas Malyshev wrote:
>
>> foo() is compatible with foo($a, $b) - since anywhere you can call function
>> declared as foo($a, $b) you can also successfully call one declared as
>> foo(), it'd just ignore extra p
Hi!
On 9/18/11 5:24 PM, Pierre Joye wrote:
class foo{
function __construct(){}
}
class bar extends foo{
function__construct($a, $b){}
}
Come on. This is not my example. My example was:
class foo{
function __construct($a, $b){}
}
class bar extends foo{
function__construct(){}
}
I woul
On Mon, Sep 19, 2011 at 1:59 AM, Stas Malyshev wrote:
> foo() is compatible with foo($a, $b) - since anywhere you can call function
> declared as foo($a, $b) you can also successfully call one declared as
> foo(), it'd just ignore extra parameters - but it is not allowed (I gave an
> example). I
Hi!
On 9/18/11 4:21 PM, Pierre Joye wrote:
The key word missing here is "compatible". We enforce (or should)
compatible signatures. And that makes totally sense.
foo() is compatible with foo($a, $b) - since anywhere you can call
function declared as foo($a, $b) you can also successfully call
On Mon, Sep 19, 2011 at 1:21 AM, Pierre Joye wrote:
> hi,
>
> On Sun, Sep 18, 2011 at 9:06 PM, Stas Malyshev wrote:
>
>> There's no matter of "breaking BC" - there's no BC issues with dropping
>> error messages, nobody's code relies on generating fatal errors for specific
>> code.
>
> Btw, afair
hi,
On Sun, Sep 18, 2011 at 9:06 PM, Stas Malyshev wrote:
> There's no matter of "breaking BC" - there's no BC issues with dropping
> error messages, nobody's code relies on generating fatal errors for specific
> code.
Btw, afair there is and was no BC as it was introduced with the
abstract sup
Hi!
On 9/18/11 11:23 AM, Nikita Popov wrote:
I didn't see any complaints about this "feature", so I don't really
see a reason why we should break BC with 5.3 here and drop the error
message.
There's no matter of "breaking BC" - there's no BC issues with dropping
error messages, nobody's code
On Sun, Sep 18, 2011 at 8:01 PM, Stas Malyshev wrote:
> 3. Some of them aren't actually a warnings but fatal errors. Example:
>
> abstract class BaseClass {
> abstract public function foo(Type1 $foo, Type2 $bar);
> }
>
> class ExtendedClass extends BaseClass {
> public function foo() {
> }
Hi!
On 9/18/11 8:09 AM, Derick Rethans wrote:
If you don't want those warnings, turn them off! That's why there is a
specific error level for it.
1. It's not possible to turn these specific warnings off. The error
level turns off all warnings on the level, not just specific ones.
2. These w
On Sun, Sep 18, 2011 at 5:09 PM, Derick Rethans wrote:
> On Sat, 17 Sep 2011, Stas Malyshev wrote:
>
>> On 9/17/11 6:27 AM, Richard Quadling wrote:
>> > With the recent BC with regard the locking of the constructor's
>> > signature for subclasses, what is the expected mechanism for allowing
>> > a
On Sat, 17 Sep 2011, Stas Malyshev wrote:
> On 9/17/11 6:27 AM, Richard Quadling wrote:
> > With the recent BC with regard the locking of the constructor's
> > signature for subclasses, what is the expected mechanism for allowing
> > a subclass to have additional parameters?
>
> I think the whole
Hi:
if this change will not revert, I will ask a more clearly error
message for this,
I report a req, https://bugs.php.net/bug.php?id=55719,
which is, the error message should told user what the correct
argument list is.
and also submitted a patch for this req.
thanks
2011/9/1
Hi !
> For one I do think that enforcing strictness, or as I see it, clean
> code and implementation, should be done in php. We did not do that in
> the past and it has created more issues than anything else in the long
> run.
+1.
> One solution to solve the need of having different methods or
>
hi,
My two cents:
For one I do think that enforcing strictness, or as I see it, clean
code and implementation, should be done in php. We did not do that in
the past and it has created more issues than anything else in the long
run.
One solution to solve the need of having different methods or
co
Hi!
On 9/17/11 2:39 PM, Richard Quadling wrote:
An interface is the absolute here. Sub classes (the super class being
abstract or otherwise), should be able to define MORE parameters (with
or without default values). Otherwise they aren't extending, but
implementing - and for me that's the role
On Sat, Sep 17, 2011 at 11:39 PM, Richard Quadling wrote:
> My question was due to the documentation commit
> http://news.php.net/php.doc.cvs/8818 and
> http://news.php.net/php.doc.cvs/8819.
Just to clarify (as I'm not sure you got that change right): PHP has
enforced signatures for methods define
On 17 September 2011 15:52, Ferenc Kovacs wrote:
> maybe Richard referring to https://bugs.php.net/bug.php?id=55085 ?
> but those change only affects the abstract classes.
>
> Tyrael
>
> On Sat, Sep 17, 2011 at 3:43 PM, Nikita Popov
> wrote:
>> Hi Richard!
>>
>> Which change are you talking abou
On Sat, Sep 17, 2011 at 20:08, Stas Malyshev wrote:
> Hi!
>
> On Sat, Sep 17, 2011 at 17:08, Laruence wrote:
>>
>>> class A { public function init($a, $b) { } }
class B extends A { public function init($a) { } }
=> PHP Strict Standards: Declaration of B::init() s
Hi!
On 9/17/11 6:27 AM, Richard Quadling wrote:
With the recent BC with regard the locking of the constructor's
signature for subclasses, what is the expected mechanism for allowing
a subclass to have additional parameters?
I think the whole "strict parameters" thing has gone into somewhat wro
Am 17.09.2011 20:08, schrieb Stas Malyshev:
> Hi!
>
>> On Sat, Sep 17, 2011 at 17:08, Laruence wrote:
class A { public function init($a, $b) { } }
class B extends A { public function init($a) { } }
=> PHP Strict Standards: Declaration of B::init() should be compa
Hi!
On Sat, Sep 17, 2011 at 17:08, Laruence wrote:
class A { public function init($a, $b) { } }
class B extends A { public function init($a) { } }
=> PHP Strict Standards: Declaration of B::init() should be compatible
with
that of A::init()
do you know any reason for this?
>> do you know any reason for this?
>>
>
> The reason for this is simply that B must act like A since every B object is
> also an object of A.
>
>
The reason for restricting the method signature in the Subclass is to
guarantee that an instance of a Subclass should work where an instance
of the Su
2011/9/17 Etienne Kneuss :
>
>
> On Sat, Sep 17, 2011 at 17:15, Laruence wrote:
>>
>> Hi:
>> this is really a big bc break...(fatal error)
>> is there any reason for us to really change this? In Yaf, there
>> are a lot of Abstract classes, the subclass only need declared there
>> argument whe
On Sat, Sep 17, 2011 at 17:15, Laruence wrote:
> Hi:
> this is really a big bc break...(fatal error)
> is there any reason for us to really change this? In Yaf, there
> are a lot of Abstract classes, the subclass only need declared there
> argument when they really need it.
>
Well, that is
2011/9/17 Etienne Kneuss :
>
>
> On Sat, Sep 17, 2011 at 17:08, Laruence wrote:
>>
>> 2011/9/17 :
>> > Hi,
>> >
>> > I think Richards intended other methods often used in combination with
>> > __construct:
>> >
>> > class A { public function init($a, $b) { } }
>> > class B extends A { p
On Sat, Sep 17, 2011 at 17:08, Laruence wrote:
> 2011/9/17 :
> > Hi,
> >
> > I think Richards intended other methods often used in combination with
> > __construct:
> >
> > class A { public function init($a, $b) { } }
> > class B extends A { public function init($a) { } }
> >
> > => PH
Hi:
this is really a big bc break...(fatal error)
is there any reason for us to really change this? In Yaf, there
are a lot of Abstract classes, the subclass only need declared there
argument when they really need it.
and I really not think this change is good one, the Intenal class
can
2011/9/17 :
> Hi,
>
> I think Richards intended other methods often used in combination with
> __construct:
>
> class A { public function init($a, $b) { } }
> class B extends A { public function init($a) { } }
>
> => PHP Strict Standards: Declaration of B::init() should be compatible wi
maybe Richard referring to https://bugs.php.net/bug.php?id=55085 ?
but those change only affects the abstract classes.
Tyrael
On Sat, Sep 17, 2011 at 3:43 PM, Nikita Popov wrote:
> Hi Richard!
>
> Which change are you talking about? I just tried doing:
> class A { public functio
Hi,
I think Richards intended other methods often used in combination with
__construct:
class A { public function init($a, $b) { } }
class B extends A { public function init($a) { } }
=> PHP Strict Standards: Declaration of B::init() should be compatible with
that of A::init()
The ex
Hi Richard!
Which change are you talking about? I just tried doing:
wrote:
> Hi.
>
> With the recent BC with regard the locking of the constructor's
> signature for subclasses, what is the expected mechanism for allowing
> a subclass to have additional parameters?
>
> You can always supply th
Hi.
With the recent BC with regard the locking of the constructor's
signature for subclasses, what is the expected mechanism for allowing
a subclass to have additional parameters?
You can always supply them and use func_get_args() / func_num_args() /
etc. to read them.
It would seem that the lim
84 matches
Mail list logo
