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
On Mon, 2011-09-19 at 12:25 +0200, Ferenc Kovacs wrote:
> >
> > Good point, are you proposing to change code and make libmysql 5.0+ a
> > requirement? If so, several changes should be made to ext/mysql, ext/mysqli
> > and PDO_MySQL.
> >
>
> I think that it is your call, but yes, I think it would r
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
>
> Good point, are you proposing to change code and make libmysql 5.0+ a
> requirement? If so, several changes should be made to ext/mysql, ext/mysqli
> and PDO_MySQL.
>
I think that it is your call, but yes, I think it would reasonable,
and it would make our/your work much easier if we would hav
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,
41 matches
Mail list logo
