Re: [PHP-DEV] __constructor parameter limitations.

[Tjerk Meesters]

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(), $flags = parent::ARRAY_AS_PROPS)
>
> while SPL ArrayObject (its parent) has this one with 3 parameters:
>
> ArrayObject::__construct() ([ mixed $input [, int $flags [, string
> $iterator_class]]] )
>
> from
>
https://github.com/zendframework/zf2/blob/master/library/Zend/Registry.phpand
> http://www.php.net/manual/en/arrayobject.construct.php
>

That's exactly why I think constructors should be exempted from "strict"
signature checking.

When you pass objects as a function parameter, the signature should match
even though you pass an instance of a child class. That has been well
established in some of the previous messages.

However, I don't think this should apply to constructors in the same way.
They can be 'simplified' as the child class becomes more specific.

> There are other similar examples, e.g.
>
> ReflectionClass::getParentClass()
> and
> ZF Zend_Reflection_Class::getParentClass($reflectionClass =
> 'Zend_Reflection_Class')
>
> I don't know if being ArrayObject an SPL makes any difference, I hope
> not...  Is the example relevant for the discussion ?
>
> I always found PHP flexibility one of its strong points, and since we
don't
> have method overloading, limiting the signature extension or contraction
> doesn't sound very useful to developers.
>
> bye!
> Devis
>
>
> On 19 September 2011 16:53, Ferenc Kovacs  wrote:
>
> > 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 sudden you error out.
> > >
> > >
> > > Well, we have no way of declaring that we accept an undefined number
of
> > > arguments. So there is simply no choice here.
> >
> > maybe we should consider adding support for that, as I agree that it
> > would make the contract more clear.
> >
> > >>  You're pushing all of the
> > >> interface declaration logic out of the interface and into code.
> > >> That's only going to create maintainability, readability and quality
> > >> issues as time goes on.  Realistically, the only good use of
> > >> func_get_args is when you need to take in an unlimited number of
> > >> arguments.  But if you do that, you should include the minimum number
> > >> in the API itself.  So if you have a function add() that can take any
> > >> number of integers, the minimum that makes sense is 2.  So you should
> > >> declare add($left, $right), and then use func_get_args to get all of
> > >> them to add together.  However, with that said, I'd argue that it's
> > >> bad design to do that at all.  I'd recommend instead taking an array
> > >> parameter and adding the elements of the array.  Not only is it
> > >> cleaner and easier to understand, it also solves the problem of
> > >> extending that functionality (so you're not duplicating the
> > >> func_get_args in each child)...
> > >>
> > >
> > > By doing that, you also do exactly what you describe earlier, you push
> > the
> > > args checks in the code itself, as you could always pass an incomplete
> > > array, and you could error out earlier.
> > >
> > > Var-args functions have been quite used for many things, there is no
> > reason
> > > why we should flag that as bad practice now... is there?
> > >
> >
> > not that I know of, except that we have no explicit way to declare
> > signature.
> >
> > to reflect to the original points by Anthony:
> > bringing up the Square - Rectangle example was a bad one, but to quote
> > from the wikipedia entry: "Violations of LSP, like this one, may or
> > may not be a problem in practice, depending on the postconditions or
> > invariants that are actually expected by the code that uses classes
> > violating LSP. Mutability is a key issue here. If Square and Rectangle
> > had only getter methods (i.e. they were immutable objects), then no
> > violation of LSP could occur."
> > So while it can cause violation, it isn't a violation by itself.
> >
> > --
> > Ferenc Kovács
> > @Tyr43l - http://tyrael.hu
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >

Re: [PHP-DEV] __constructor parameter limitations.

[devis]

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 ArrayObject (its parent) has this one with 3 parameters:

ArrayObject::__construct() ([ mixed $input [, int $flags [, string
$iterator_class]]] )

from
https://github.com/zendframework/zf2/blob/master/library/Zend/Registry.phpand
http://www.php.net/manual/en/arrayobject.construct.php

There are other similar examples, e.g.

ReflectionClass::getParentClass()
and
ZF Zend_Reflection_Class::getParentClass($reflectionClass =
'Zend_Reflection_Class')

I don't know if being ArrayObject an SPL makes any difference, I hope
not...  Is the example relevant for the discussion ?

I always found PHP flexibility one of its strong points, and since we don't
have method overloading, limiting the signature extension or contraction
doesn't sound very useful to developers.

bye!
Devis


On 19 September 2011 16:53, Ferenc Kovacs  wrote:

> 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 sudden you error out.
> >
> >
> > Well, we have no way of declaring that we accept an undefined number of
> > arguments. So there is simply no choice here.
>
> maybe we should consider adding support for that, as I agree that it
> would make the contract more clear.
>
> >>  You're pushing all of the
> >> interface declaration logic out of the interface and into code.
> >> That's only going to create maintainability, readability and quality
> >> issues as time goes on.  Realistically, the only good use of
> >> func_get_args is when you need to take in an unlimited number of
> >> arguments.  But if you do that, you should include the minimum number
> >> in the API itself.  So if you have a function add() that can take any
> >> number of integers, the minimum that makes sense is 2.  So you should
> >> declare add($left, $right), and then use func_get_args to get all of
> >> them to add together.  However, with that said, I'd argue that it's
> >> bad design to do that at all.  I'd recommend instead taking an array
> >> parameter and adding the elements of the array.  Not only is it
> >> cleaner and easier to understand, it also solves the problem of
> >> extending that functionality (so you're not duplicating the
> >> func_get_args in each child)...
> >>
> >
> > By doing that, you also do exactly what you describe earlier, you push
> the
> > args checks in the code itself, as you could always pass an incomplete
> > array, and you could error out earlier.
> >
> > Var-args functions have been quite used for many things, there is no
> reason
> > why we should flag that as bad practice now... is there?
> >
>
> not that I know of, except that we have no explicit way to declare
> signature.
>
> to reflect to the original points by Anthony:
> bringing up the Square - Rectangle example was a bad one, but to quote
> from the wikipedia entry: "Violations of LSP, like this one, may or
> may not be a problem in practice, depending on the postconditions or
> invariants that are actually expected by the code that uses classes
> violating LSP. Mutability is a key issue here. If Square and Rectangle
> had only getter methods (i.e. they were immutable objects), then no
> violation of LSP could occur."
> So while it can cause violation, it isn't a violation by itself.
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] __constructor parameter limitations.

[Ferenc Kovacs]

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 sudden you error out.
>
>
> Well, we have no way of declaring that we accept an undefined number of
> arguments. So there is simply no choice here.

maybe we should consider adding support for that, as I agree that it
would make the contract more clear.

>>  You're pushing all of the
>> interface declaration logic out of the interface and into code.
>> That's only going to create maintainability, readability and quality
>> issues as time goes on.  Realistically, the only good use of
>> func_get_args is when you need to take in an unlimited number of
>> arguments.  But if you do that, you should include the minimum number
>> in the API itself.  So if you have a function add() that can take any
>> number of integers, the minimum that makes sense is 2.  So you should
>> declare add($left, $right), and then use func_get_args to get all of
>> them to add together.  However, with that said, I'd argue that it's
>> bad design to do that at all.  I'd recommend instead taking an array
>> parameter and adding the elements of the array.  Not only is it
>> cleaner and easier to understand, it also solves the problem of
>> extending that functionality (so you're not duplicating the
>> func_get_args in each child)...
>>
>
> By doing that, you also do exactly what you describe earlier, you push the
> args checks in the code itself, as you could always pass an incomplete
> array, and you could error out earlier.
>
> Var-args functions have been quite used for many things, there is no reason
> why we should flag that as bad practice now... is there?
>

not that I know of, except that we have no explicit way to declare signature.

to reflect to the original points by Anthony:
bringing up the Square - Rectangle example was a bad one, but to quote
from the wikipedia entry: "Violations of LSP, like this one, may or
may not be a problem in practice, depending on the postconditions or
invariants that are actually expected by the code that uses classes
violating LSP. Mutability is a key issue here. If Square and Rectangle
had only getter methods (i.e. they were immutable objects), then no
violation of LSP could occur."
So while it can cause violation, it isn't a violation by itself.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[Etienne Kneuss]

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
> the LSP.  In fact, it's unsolvable using inheritance.  For information
> as to why, check out this article:
> http://en.wikipedia.org/wiki/Circle-ellipse_problem
>
> As far as those who say that this is not an LSP issue, it actually is.
>  Look at the LSP definition again.  I'll post it here:
>
> > Let q(x) be a property provable about objects x of type T. Then q(y)
> should be provable for objects y of type S where S is a subtype of T.
>
> That means that extending methods actually cannot be more general than
> the parent.  More generic breaks since another subtype of the parent
> class is free to not make the generalization and hence break the
> substitution ability.  And more specific breaks the substitution as
> well since it if you swap out a more generic method with a more
> specific one, it can break everything.
>
> Let's be clear here.  This is not about *what works*, but about what
> is known to work.  To see the problem with breaking signatures, let's
> look at the three cases (interface, abstract class and inheritance.
>
> Interfaces are a contract between your implementation and the outside
> world.  The method signature is the contract.  It's telling everyone
> that uses it (not implements, but type hints against) that all
> implementations that it receives will behave to that contract.  Sure,
> we could go with duck typing and just provide the method name (no
> arguments) in the interface, but that's a pretty lousy contract.  At
> 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
> you'll violate the contract and couple to the implementation instead
> of the interface.  This causes the checked polymorphic ability of the
> interface to go out the window.  The result is that the interface
> becomes completely useless.  So, in order for interfaces to be useful,
> they should include the exact arguments in order and in type, and the
> runtime (PHP) should enforce that (which it does).
>
> Abstract classes are a contract between your implementation and the
> parent class only.  They are used when you're implementing
> functionality, and you leave some methods for the child to define.
> But these definitions are important since the parent is likely calling
> them directly (or implementing part of an interface, in which the
> abstract method becomes an interface contract).  So the parent is
> expecting a specific signature, and the child is expected to implement
> it.  Now, the interesting thing here, is that in non-interface
> abstract class methods, generalization is ok in the child.  You can
> make the child method more general (take more arguments, take broader
> arguments, etc) as long as it still behaves according to the interface
> provided.  This is because the contract is to a known implementation
> (the parent), it's not a general contract.  But in PHP, you can't do
> that since it uses the same contract enforcer for interfaces as it
> does for abstract classes.
>
> Overriding Methods are seemingly contractless, so you should be able
> to change the method signature from subclass to subclass.  Indeed, on
> a simple first look, this makes sense.  However, when we start to look
> at it, it becomes apparent that there is actually a contract in place
> due to the LSP.  We can't change the function signature, since we
> expect all subtypes of T will be able to be swapped for each other.
> If we could change signatures, we'd loose this ability and hence
> violate LSP.  Plus, this would also make the code completely resistant
> to the fundamental principle of OOP, polymorphism.  Sure, you could
> swap out some of the subclasses, but not all.  So all of a sudden, by
> loosening the restrictions on extended method parameters, we're
> actually causing tighter coupling and all but eliminating the benefits
> of OOP in general.
>

Uh unless I'm misunderstanding you here there is something that looks
terribly wrong:

Overriding methods with a  different signature, e.g. allowing more sets of
arguments(contra variant args), or returning a more precise type (covariant
return type) definitely works with LSP, and it is fine in OO. LSP only
states about substitution between one parent and its child, not one child
with another...


>
>
>
> 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 sudden you error out.


Well, we have no way of declaring that we accept an undefined number of
arguments. So

Re: [PHP-DEV] __constructor parameter limitations.

[Anthony Ferrara]

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 why, check out this article:
http://en.wikipedia.org/wiki/Circle-ellipse_problem

As far as those who say that this is not an LSP issue, it actually is.
 Look at the LSP definition again.  I'll post it here:

> Let q(x) be a property provable about objects x of type T. Then q(y) should 
> be provable for objects y of type S where S is a subtype of T.

That means that extending methods actually cannot be more general than
the parent.  More generic breaks since another subtype of the parent
class is free to not make the generalization and hence break the
substitution ability.  And more specific breaks the substitution as
well since it if you swap out a more generic method with a more
specific one, it can break everything.

Let's be clear here.  This is not about *what works*, but about what
is known to work.  To see the problem with breaking signatures, let's
look at the three cases (interface, abstract class and inheritance.

Interfaces are a contract between your implementation and the outside
world.  The method signature is the contract.  It's telling everyone
that uses it (not implements, but type hints against) that all
implementations that it receives will behave to that contract.  Sure,
we could go with duck typing and just provide the method name (no
arguments) in the interface, but that's a pretty lousy contract.  At
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
you'll violate the contract and couple to the implementation instead
of the interface.  This causes the checked polymorphic ability of the
interface to go out the window.  The result is that the interface
becomes completely useless.  So, in order for interfaces to be useful,
they should include the exact arguments in order and in type, and the
runtime (PHP) should enforce that (which it does).

Abstract classes are a contract between your implementation and the
parent class only.  They are used when you're implementing
functionality, and you leave some methods for the child to define.
But these definitions are important since the parent is likely calling
them directly (or implementing part of an interface, in which the
abstract method becomes an interface contract).  So the parent is
expecting a specific signature, and the child is expected to implement
it.  Now, the interesting thing here, is that in non-interface
abstract class methods, generalization is ok in the child.  You can
make the child method more general (take more arguments, take broader
arguments, etc) as long as it still behaves according to the interface
provided.  This is because the contract is to a known implementation
(the parent), it's not a general contract.  But in PHP, you can't do
that since it uses the same contract enforcer for interfaces as it
does for abstract classes.

Overriding Methods are seemingly contractless, so you should be able
to change the method signature from subclass to subclass.  Indeed, on
a simple first look, this makes sense.  However, when we start to look
at it, it becomes apparent that there is actually a contract in place
due to the LSP.  We can't change the function signature, since we
expect all subtypes of T will be able to be swapped for each other.
If we could change signatures, we'd loose this ability and hence
violate LSP.  Plus, this would also make the code completely resistant
to the fundamental principle of OOP, polymorphism.  Sure, you could
swap out some of the subclasses, but not all.  So all of a sudden, by
loosening the restrictions on extended method parameters, we're
actually causing tighter coupling and all but eliminating the benefits
of OOP in general.



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 sudden you error out.  You're pushing all of the
interface declaration logic out of the interface and into code.
That's only going to create maintainability, readability and quality
issues as time goes on.  Realistically, the only good use of
func_get_args is when you need to take in an unlimited number of
arguments.  But if you do that, you should include the minimum number
in the API itself.  So if you have a function add() that can take any
number of integers, the minimum that makes sense is 2.  So you should
declare add($left, $right), and then use func_get_args to get all of
them to add together.  However, with that said, I'd argue that it's
bad design to do that at all.  I'd recommend instead taking an a

[PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/mysqli/mysqli_api.c branches/PHP_5_4/ext/mysqli/mysqli_api.c trunk/ext/mysqli/mysqli_api.c

[Johannes Schlüter]

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 reasonable,
> and it would make our/your work much easier if we would have to
> support fewer major versions.

While we can't change requirements in bug fix versions (5.3.x) and not
sure this is a good thing to do during beta (5.4)

johannes



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[Laruence]

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 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 of an abstract method should match the
 signature,
 while overriding a method should be able to loosen the precondition in
 many ways (type hints change, less arguments, etc..), IMO.


>>> I should like to hear why. As far as I can see, there's absolutely no
>>> difference. All I've seen in this thread to this respect are semantic
>>> pseudo-arguments.
>>>
>>
>> Well it is about semantics, and IMO defining a method as abstract is some
>> sort of declaration, and this declaration should be respected when the
>> method is actually implemented.
>>
>> On the other hand, interfaces define usage capabilities, and those usages
>> should work.
>>
>> There might be close to no difference in the way the are internall handled
>> currently, but IMO there is a semantic difference between the two.
>>
>
> Given that the discussion has now gone into many directions:
> - constructors/normal methods
> - abstract/interfaces/overriding
>
> Let me write some small RFC describing what we currently do w.r.t. prototype
> checks, and also summarize what people propose as changes to them. We can
> then discuss those and eventually vote for the way to go forward.
That will be nice, thanks.
>
>
>>
>>
>>> I'd say interfaces are much more likely to include more useless parameters
>>> than a concrete method definition, which most likely will only include the
>>> arguments it actually needs.
>>>
>>> An example:
>>>
>>> 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 the other search results).
>>
>>
>>> --
>>> Gustavo Lopes
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>
>>
>> --
>> Etienne Kneuss
>> http://www.colder.ch
>>
>
>
>
> --
> Etienne Kneuss
> http://www.colder.ch
>



-- 
Laruence  Xinchen Hui
http://www.laruence.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[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 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 of an abstract method should match the
>>> signature,
>>> while overriding a method should be able to loosen the precondition in
>>> many ways (type hints change, less arguments, etc..), IMO.
>>>
>>>
>> I should like to hear why. As far as I can see, there's absolutely no
>> difference. All I've seen in this thread to this respect are semantic
>> pseudo-arguments.
>>
>
> Well it is about semantics, and IMO defining a method as abstract is some
> sort of declaration, and this declaration should be respected when the
> method is actually implemented.
>
> On the other hand, interfaces define usage capabilities, and those usages
> should work.
>
> There might be close to no difference in the way the are internall handled
> currently, but IMO there is a semantic difference between the two.
>

Given that the discussion has now gone into many directions:
- constructors/normal methods
- abstract/interfaces/overriding

Let me write some small RFC describing what we currently do w.r.t. prototype
checks, and also summarize what people propose as changes to them. We can
then discuss those and eventually vote for the way to go forward.


>
>
>> I'd say interfaces are much more likely to include more useless parameters
>> than a concrete method definition, which most likely will only include the
>> arguments it actually needs.
>>
>> An example:
>>
>> 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 the other search results).
>
>
>> --
>> Gustavo Lopes
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
> --
> Etienne Kneuss
> http://www.colder.ch
>



-- 
Etienne Kneuss
http://www.colder.ch

Re: [PHP-DEV] __constructor parameter limitations.

[Etienne Kneuss]

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 same. So the above doesn't really apply.
>>
>> The initial implementation of an abstract method should match the
>> signature,
>> while overriding a method should be able to loosen the precondition in
>> many ways (type hints change, less arguments, etc..), IMO.
>>
>>
> I should like to hear why. As far as I can see, there's absolutely no
> difference. All I've seen in this thread to this respect are semantic
> pseudo-arguments.
>

Well it is about semantics, and IMO defining a method as abstract is some
sort of declaration, and this declaration should be respected when the
method is actually implemented.

On the other hand, interfaces define usage capabilities, and those usages
should work.

There might be close to no difference in the way the are internall handled
currently, but IMO there is a semantic difference between the two.


> I'd say interfaces are much more likely to include more useless parameters
> than a concrete method definition, which most likely will only include the
> arguments it actually needs.
>
> An example:
>
> 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
> the other search results).
>
> --
> Gustavo Lopes
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Etienne Kneuss
http://www.colder.ch

Re: [PHP-DEV] __constructor parameter limitations.

[Gustavo Lopes]

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 most common scenario for implementations of this interface  
(see the other search results).


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 that.



There's no significant difference between interfaces and abstract classes  
here. Abstract classes frequently have protected hook methods you can  
override/implement take more arguments that you need. For instance, you  
could have:


class Form {
...
abstract protected function buildHTML($page, $errors, $params, $command);
...
}

and reasonably not need all the arguments.


--
Gustavo Lopes

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[Etienne Kneuss]

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 how likely it is to a
>>> mistake.
>>>
>>
>> It is not little useful and it is not likely to make such mistake without
>> immediately being notified and corrected.
>>
>
> In the cases where you do want to ignore arguments (say overgenerous
> interfaces that give you more information than you need to make a
> decision), relaxing the parameter checks would not be very helpful:
>
> * It had to be case that the parameters you want to ignore are the last
> * You could just put the arguments in the signature and still ignore them
> (perhaps also giving them a dummy default value so that they don't have to
> be passed).
>
> So there's little to be gained here.
>

There is surely little to be gained here, but that's not really the point.
The point is that we are currently diverging from the theory, so we should
have a BIG gain of doing so, not the opposite.


>
> --
> Gustavo Lopes
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Etienne Kneuss
http://www.colder.ch

Re: [PHP-DEV] __constructor parameter limitations.

[Ferenc Kovacs]

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 most common scenario for implementations of this interface (see
>> the other search results).
>
> 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 that.

how would you have concrete methods in your interfaces?
you can do that with abstract, but you can't do that with interface.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/mysqli/mysqli_api.c branches/PHP_5_4/ext/mysqli/mysqli_api.c trunk/ext/mysqli/mysqli_api.c

[Ferenc Kovacs]

>
> 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 have to
support fewer major versions.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[Pierre Joye]

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
> the other search results).

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 that.


-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[Gustavo Lopes]

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 of an abstract method should match the  
signature,
while overriding a method should be able to loosen the precondition in  
many ways (type hints change, less arguments, etc..), IMO.




I should like to hear why. As far as I can see, there's absolutely no  
difference. All I've seen in this thread to this respect are semantic  
pseudo-arguments.


I'd say interfaces are much more likely to include more useless parameters  
than a concrete method definition, which most likely will only include the  
arguments it actually needs.


An example:

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 the other search results).


--
Gustavo Lopes

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[Etienne Kneuss]

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 you can have :
>
> class A { public function f($a) { ... } }
> class A1 extends A { public function f($a = null) { ... } }
> class A2 extends A { public function f($a, $b = null) { ... } }
>
> BUT You can't have :
>
> class A3 extends A { public function f() { ... } }
>

Sure you can. With function A3::f() you can both call $a3->f() and
$a3->f(any $a that would work with A), any usage of A3 as a A will work just
fine, and this is the criteria.


>
> I'm agree that it's valid from PHP point of view because the language does
> not handle the argument in $a3->f(uniqid()), but it's totaly invalid from
> OOP point of view.
>
> So if it's invalid for "normal" method, it's more invalid for abstract
> method, even if abstract method is constructor.
> Abstract method define a MANDATORY interface.
> So you can have :
>
> abstract class A { public abstract function f($a); }
> class A1 extends A { public function f($a = null) { ... } }
> class A2 extends A { public function f($a, $b = null) { ... } }
>
> BUT You can't have :
>
> class A3 extends A { public function f() { ... } }
>
> And the use of func_get_args() is not incompatible with that :
>
> class A4 extends A {
>  public function ($a) {
>$variadicArgs = array_slice(func_get_args(), 1);
>  }
> }
>
> Best regard,
>
> Fred
>
> --
> ==**==**
> 
> Frédéric Hardy : Architecte d'application/Admin. système/Ergonome
>   CV : 
> http://blog.mageekbox.net/**public/cv.frederic.hardy.pdf
> Blog : http://blog.mageekbox.net
>  Twitter : http://twitter.com/mageekguy
> ==**==**
> 
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Etienne Kneuss
http://www.colder.ch

Re: [PHP-DEV] __constructor parameter limitations.

[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 you can have :

class A { public function f($a) { ... } }
class A1 extends A { public function f($a = null) { ... } }
class A2 extends A { public function f($a, $b = null) { ... } }

BUT You can't have :

class A3 extends A { public function f() { ... } }

I'm agree that it's valid from PHP point of view because the language 
does not handle the argument in $a3->f(uniqid()), but it's totaly 
invalid from OOP point of view.


So if it's invalid for "normal" method, it's more invalid for abstract 
method, even if abstract method is constructor.

Abstract method define a MANDATORY interface.
So you can have :

abstract class A { public abstract function f($a); }
class A1 extends A { public function f($a = null) { ... } }
class A2 extends A { public function f($a, $b = null) { ... } }

BUT You can't have :

class A3 extends A { public function f() { ... } }

And the use of func_get_args() is not incompatible with that :

class A4 extends A {
  public function ($a) {
$variadicArgs = array_slice(func_get_args(), 1);
  }
}

Best regard,
Fred

--

Frédéric Hardy : Architecte d'application/Admin. système/Ergonome
   CV : http://blog.mageekbox.net/public/cv.frederic.hardy.pdf
 Blog : http://blog.mageekbox.net
  Twitter : http://twitter.com/mageekguy



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[Ferenc Kovacs]

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, so thanks for pointing that out.
>>
>
> I mostly agree with you, with these exceptions:
>
> * No catchable fatal error -- E_STRICT or E_NOTICE.
Ok, from the responses, I changed my mind already about the fatal.

> * There's no reason checking typehints contravariance would be particularly
> difficult.

we discussed this with ekneuss on irc, and the big change would be,
that currently the typehints only checked in runtime, to enforce the
signature, the check should be done when the Subclass definition is
parsed by the engine (when it would have to autoload, the typehinted
class, etc. and it would require traversing the class hierarchy. which
would also create some performance penalty compared to the old
behavior)
the other thing, what ekneuss also pointed out, that in my example, I
mentioned allowing overriding the typehint from Superclass to
Subclass, but the opposite (allowing Super where Super was used in the
parent) would be more in line with the "allow to override as long as
it is more general than the parent" idea.

> * Allowing less arguments in subclasses, as I've argued in the thread.
I think that I mentioned that, maybe only after that mail, so yes, I'm
also support this, see my Square example in this thread.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[Pierre Joye]

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 with Y < X
>> The procondition of the subclass method is looser. And this is perfectly
>> fine.
>> You may debate whether it is "at least X" or not that the prototype
>> defines, but that's exactly what it does and how PHP w.r.t. to function
>> calls work, we have always allowed more arguments in the call than functions
>> declares.
>
> 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 of an abstract method should match the signature,
> while overriding a method should be able to loosen the precondition in many
> ways (type hints change, less arguments, etc..), IMO.

Exactly. Abstract is a different than interface or simple extended
classes. That's something I totally fail to make clear in this lengthy
thread.

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[Etienne Kneuss]

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 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 declaration
>> that
>> > has nothing to do with OO. You want to prove you point - prove it, not
>> > repeat it.
>>
>> With the risk to sound harsh, please do your home work and stop to ask
>> me (or other) to go fetch quotes from very well kown OO programming
>> reference and paste them here. Thanks for your understanding.
>>
>
> 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 with Y < X
>
> The procondition of the subclass method is looser. And this is perfectly
> fine.
>
> You may debate whether it is "at least X" or not that the prototype
> defines, but that's exactly what it does and how PHP w.r.t. to function
> calls work, we have always allowed more arguments in the call than functions
> declares.
>

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 of an abstract method should match the signature,
while overriding a method should be able to loosen the precondition in many
ways (type hints change, less arguments, etc..), IMO.


>
>
>>
>> Cheers,
>> --
>> Pierre
>>
>> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
> --
> Etienne Kneuss
> http://www.colder.ch
>



-- 
Etienne Kneuss
http://www.colder.ch

Re: [PHP-DEV] __constructor parameter limitations.

[Richard Quadling]

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 !
>> Moreover, i think that it's not compatible with Liskov substitution
>> principle.
> Subclasses can loosen the preconditions, that's eactly what happens here and
> it is perfectly fine in theory.

WOW. I really didn't expect this as a response to what, for me, was
quite an innocent question. Normally I get a 3 comments pointing me in
the right direction and I'm happy.



Maybe its me. But something that is abstract certain implies to me a
loose idea. The keywords have inherent meaning. At least in English.


If a class, abstract or otherwise, has the requirement to have an
enforced parameter list for a method, then would seem to be the role
of an interface. An abstract class and an method declared in an
interface, both require implementation. But with an interface, you are
not able to change the parameters. would seem to satisfy LSP.

Unless you use an interface to enforce the parameter order, how else
do you guarantee the contract?

If you also enforce the parameters for other methods (abstract or
otherwise - I'm still not 100% on the reason for the difference - or,
at this stage, if there even is a difference), then interfaces are
seemingly redundant.

Take the following code ...




The signatures here feel completely right, though MAYBE one could
argue that SuperCrete's constructor is off because $c is not optional.

I don't think $a and $b can ever become optional or missing from any
sub-class' definition.


As things stand, 5.4.0-beta doesn't report any problem with this code.


Have I made a mountain out of a mole hill?
(http://en.wikipedia.org/wiki/Make_a_mountain_out_of_a_molehill for
those who don't know the English idiom).








-- 
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[Ferenc Kovacs]

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 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 notified and corrected. I don't know how you make these
>> assumptions or what they are based on - could you please bring some
>> evidence?
>
> It would obviously be hard to produce such evidence. Measuring how common
> a mistake is very difficult without some study to that effect since those
> mistakes are steeply underrepresented in the public PHP code corpus (i.e.
> they get fixed). And measuring how common overrides with less arguments
> are would still require relatively complex code analysis.
>
> So, no, I cannot prove the assertions behind my argument, I can only say I
> believe them to be plausible.
>
>>> And I don't buy the func_get_args() argument. Why would anyone use
>>> func_get_args for anything other than variadic functions?... I certainly
>>> don't.
>>
>> So you say if you personally don't use something in PHP nobody should use
>> it?
>> And, BTW, what's wrong with variadic functions (i.e., ones accepting
>> variable number of arguments)? Such functions are commonplace in PHP.
>
> 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) {}
> }
>
> Because for all we know the implementation of A::foo() could have:
>
> function foo() {
>        $a = func_get_args()[0];
> }
yeah, but you can't know from the method signature that there is, or
isn't any place, where the parent method is called without arguments,
but your class would be incompatible there.

You aren't supposed to know at all time that what does the Superclass
class/method internally or how is it used at all time(where it is
called, with how many arguments, etc), but you get a guarantee that
all call for that method has to be compatible with it's method
signature, so as long as your method signature also compatible with
it, you should be fine to change it.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[Gustavo Lopes]

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 not likely to make such mistake  
without immediately being notified and corrected.


In the cases where you do want to ignore arguments (say overgenerous
interfaces that give you more information than you need to make a
decision), relaxing the parameter checks would not be very helpful:

* It had to be case that the parameters you want to ignore are the last
* You could just put the arguments in the signature and still ignore them
(perhaps also giving them a dummy default value so that they don't have to
be passed).

So there's little to be gained here.

--
Gustavo Lopes

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[Ferenc Kovacs]

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 enforced, this
>>> doesn't make sense anymore. You could just as well drop the signature
>>> from abstract method definitions, as it's pointless then.
>>
>> No it is not. The signature tells "this method would accept certain
>> arguments". If you call it with these arguments, it would work. However,
>> there's no promise to never extend the cases where it works - it goes
>> contrary to the whole point of OOP to say "I will never loosen preconditions
>> on my methods".
>
> While this is true, we should be a bit pragmatic here.
>
> 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
> being the case) for arguments to be simply intentionally ignored. In fact, I
> don't know of any popular language that implements this type of
> contravariance. Plus, consider the case in which the superclass takes an
> argument by reference:
>
> function increment(&$foo) { $foo = $foo + 1; }
>
> It is obvious that in this case a subclass override that takes no arguments
> cannot possibly satisfy the contract of the original method. That is to say,
> by ref arguments are also used for postconditions.
>
> That said, I think the only rules worth implementing are:
>
> * Allow arguments with a supertype. For instance, this should give no
> warning:
>
>  class A {}
> class B extends A {}
> class C { function g(B $b) {} }
> class D extends C { function g(A $a) { } }
>
> * Allow extra parameters with a default value (implemented):
>
>  class C { function g($a) {} }
> class D extends C { function g($a,$b=true) { } }
>

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, so thanks for pointing that out.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[Gustavo Lopes]

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 not likely to make such mistake  
without immediately being notified and corrected. I don't know how you  
make these assumptions or what they are based on - could you please  
bring some evidence?


It would obviously be hard to produce such evidence. Measuring how common
a mistake is very difficult without some study to that effect since those
mistakes are steeply underrepresented in the public PHP code corpus (i.e.
they get fixed). And measuring how common overrides with less arguments
are would still require relatively complex code analysis.

So, no, I cannot prove the assertions behind my argument, I can only say I
believe them to be plausible.


And I don't buy the func_get_args() argument. Why would anyone use
func_get_args for anything other than variadic functions?... I certainly
don't.


So you say if you personally don't use something in PHP nobody should  
use it?
And, BTW, what's wrong with variadic functions (i.e., ones accepting  
variable number of arguments)? Such functions are commonplace in PHP.


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) {}
}

Because for all we know the implementation of A::foo() could have:

function foo() {
$a = func_get_args()[0];
}

--
Gustavo Lopes

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[Ferenc Kovacs]

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 for disallowing this with nornal args though.
>> Imagine the following code:
>>
>> interface Foo { public function plop ($a,$b,$c,$d) }
>>
>> class A implements Foo {
>>   public function plop() {
>>      $args = func_get_args();
>>      // ...
>>   }
>> }
>>
>> This is perfectly valid PHP code, there is no valid usage of Foo that will
>> not work with A... So to me this restriction seems really arbitrary.
>> And I don;t believe missing an argument in the declaration of a method,
>> using it in the body of the method and not realising it is so much of a
>> common error that it would warrant this.
>>
>
> 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.
>
> And I don't buy the func_get_args() argument. Why would anyone use
> func_get_args for anything other than variadic functions?... I certainly
> don't.
>

Lester mentioned another use-case, when the Subclass will call the
parent method with constant values as arguments.
For example I have Quadrilateral Superclass with the public function
__construct($width, $height){}
If I create a more special Subclass: Square, I can omit the second
parameter, as I know that for Square, the $width and $height is equal.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[Etienne Kneuss]

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 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 declaration
> that
> > has nothing to do with OO. You want to prove you point - prove it, not
> > repeat it.
>
> With the risk to sound harsh, please do your home work and stop to ask
> me (or other) to go fetch quotes from very well kown OO programming
> reference and paste them here. Thanks for your understanding.
>

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 with Y < X

The procondition of the subclass method is looser. And this is perfectly
fine.

You may debate whether it is "at least X" or not that the prototype defines,
but that's exactly what it does and how PHP w.r.t. to function calls work,
we have always allowed more arguments in the call than functions declares.


>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Etienne Kneuss
http://www.colder.ch

Re: [PHP-DEV] __constructor parameter limitations.

[Pierre Joye]

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 is
> prohibited. Only example you brought so far is C function declaration that
> has nothing to do with OO. You want to prove you point - prove it, not
> repeat it.

With the risk to sound harsh, please do your home work and stop to ask
me (or other) to go fetch quotes from very well kown OO programming
reference and paste them here. Thanks for your understanding.

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[Stas Malyshev]

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 notified and corrected. I don't know how you 
make these assumptions or what they are based on - could you please 
bring some evidence?



And I don't buy the func_get_args() argument. Why would anyone use
func_get_args for anything other than variadic functions?... I certainly
don't.


So you say if you personally don't use something in PHP nobody should 
use it?
And, BTW, what's wrong with variadic functions (i.e., ones accepting 
variable number of arguments)? Such functions are commonplace in PHP.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[Etienne Kneuss]

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
> principle.


Subclasses can loosen the preconditions, that's eactly what happens here and
it is perfectly fine in theory.


>
>
> Best regards,
> Fred
> --
>
> ==**==**
> 
> Frédéric Hardy : Architecte d'application/Admin. système/Ergonome
>   CV : 
> http://blog.mageekbox.net/**public/cv.frederic.hardy.pdf
> Blog : http://blog.mageekbox.net
>  Twitter : http://twitter.com/mageekguy
> ==**==**
> 
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Etienne Kneuss
http://www.colder.ch

Re: [PHP-DEV] __constructor parameter limitations.

[Stas Malyshev]

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
principle (http://en.wikipedia.org/wiki/Liskov_substitution_principle).


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.
As for your claim that without this restriction abstract methods are 
useless for you - if you're using them for this, you're already using 
them wrong. No code should rely on other code failing.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[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
principle.

Best regards,
Fred
--


Frédéric Hardy : Architecte d'application/Admin. système/Ergonome
   CV : http://blog.mageekbox.net/public/cv.frederic.hardy.pdf
 Blog : http://blog.mageekbox.net
  Twitter : http://twitter.com/mageekguy




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[Gustavo Lopes]

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 code:

interface Foo { public function plop ($a,$b,$c,$d) }

class A implements Foo {
   public function plop() {
  $args = func_get_args();
  // ...
   }
}

This is perfectly valid PHP code, there is no valid usage of Foo that  
will not work with A... So to me this restriction seems really arbitrary.

And I don;t believe missing an argument in the declaration of a method,
using it in the body of the method and not realising it is so much of a
common error that it would warrant this.



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.


And I don't buy the func_get_args() argument. Why would anyone use  
func_get_args for anything other than variadic functions?... I certainly  
don't.


--
Gustavo Lopes

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[Stas Malyshev]

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 declaration 
that has nothing to do with OO. You want to prove you point - prove it, 
not repeat it.



You are claiming that only way in OO to implement contacts is have the whole 
hierarchy enforce exactly
the same function signatures


You miss one word, abstract. And that's what you actually do not
understand or does not want to.


1. Non-abstract methods have the same problem, as I have already shown you.

2. Abstract has nothing to do with it, abstract just says there's no 
default implementation provided so protocol implementor must always 
override it. The fact that abstract in PHP works differently is an 
artifact of supporting BC, as you yourself recently explained. I don't 
know where the notion that abstract methods must have different 
signature enforcement and inheritance rules and it's somehow "known 
principle" comes from. Its totally not what abstract means in all OO 
languages known to me. Could you please cite OO languages that have 
different signature enforcement rules for abstracts and non-abstracts?

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[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 
principle (http://en.wikipedia.org/wiki/Liskov_substitution_principle).


Best regards,
Fred
--


Frédéric Hardy : Architecte d'application/Admin. système/Ergonome
   CV : http://blog.mageekbox.net/public/cv.frederic.hardy.pdf
 Blog : http://blog.mageekbox.net
  Twitter : http://twitter.com/mageekguy



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[Stas Malyshev]

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 substituted defaults or overrode values for 
some parameters. I never had a code (which survived longer than 2 
minutes without editing) where one just forgot to specify arguments to a 
method that's using them - any half-decent IDE would discover that in 
seconds and alert you. I don;t think it's a place of the engine to 
decide perfectly valid language use is a "mistake" and throw errors just 
because somebody dislikes it.



being the case) for arguments to be simply intentionally ignored. In fact,
I don't know of any popular language that implements this type of
contravariance. Plus, consider the case in which the superclass takes an


Most languages that check signatures are compiled languages, in which 
variable arguments are implemented differently than in PHP. For example, 
Python doesn't have this kind of signature enforcement at all (so you 
could claim it allows this type of contravariance, too) - and yet you 
don't think this is the reason we have to abandon it, right?



argument by reference:

function increment(&$foo) { $foo = $foo + 1; }

It is obvious that in this case a subclass override that takes no
arguments cannot possibly satisfy the contract of the original method.


In this particular case it would not be right, but it's not the reason 
to prohibit it in many other cases where it is. The fact that you can 
write wrong code if you try really hard shouldn't be a reason to prevent 
perfectly correct code from working.



* Allow arguments with a supertype. For instance, this should give no
warning:
* Allow extra parameters with a default value (implemented):


* Allow ignoring parameters or introducing defaults
* Remove fatal errors. Fatal errors should be when the engine can not 
continue, not when the code is perfectly workable but we frown upon such 
use of the language. This is especially true in non-compiled language 
where all fatal errors break application in runtime.


--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[Pierre Joye]

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 killing me.

> You are claiming that only way in OO to implement contacts is have the whole 
> hierarchy enforce exactly
> the same function signatures

You miss one word, abstract. And that's what you actually do not
understand or does not want to.

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[Etienne Kneuss]

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 enforced, this
>>> doesn't make sense anymore. You could just as well drop the signature
>>> from abstract method definitions, as it's pointless then.
>>>
>>
>> No it is not. The signature tells "this method would accept certain
>> arguments". If you call it with these arguments, it would work. However,
>> there's no promise to never extend the cases where it works - it goes
>> contrary to the whole point of OOP to say "I will never loosen preconditions
>> on my methods".
>>
>
> While this is true, we should be a bit pragmatic here.
>
> 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
> being the case) for arguments to be simply intentionally ignored. In fact, I
> don't know of any popular language that implements this type of
> contravariance. Plus, consider the case in which the superclass takes an
> argument by reference:
>
> function increment(&$foo) { $foo = $foo + 1; }
>
> It is obvious that in this case a subclass override that takes no arguments
> cannot possibly satisfy the contract of the original method. That is to say,
> by ref arguments are also used for postconditions.
>

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 code:

interface Foo { public function plop ($a,$b,$c,$d) }

class A implements Foo {
   public function plop() {
  $args = func_get_args();
  // ...
   }
}

This is perfectly valid PHP code, there is no valid usage of Foo that will
not work with A... So to me this restriction seems really arbitrary.
And I don;t believe missing an argument in the declaration of a method,
using it in the body of the method and not realising it is so much of a
common error that it would warrant this.


>
> That said, I think the only rules worth implementing are:
>
> * Allow arguments with a supertype. For instance, this should give no
> warning:


>  class A {}
> class B extends A {}
> class C { function g(B $b) {} }
> class D extends C { function g(A $a) { } }
>
> * Allow extra parameters with a default value (implemented):
>
>  class C { function g($a) {} }
> class D extends C { function g($a,$b=true) { } }
>
> --
> Gustavo Lopes
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Etienne Kneuss
http://www.colder.ch

Re: [PHP-DEV] __constructor parameter limitations.

[Stas Malyshev]

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 basic of abstract
methods/classes.


There can be many implementations of the same protocol, that's the point 
of OOP (which has nothing to do with C or C function declarations, which 
and not overridable and as such do not define any protocols but just 
functions themselves). Your idea is that somehow only identically 
copying signatures instead of extending them is possible, and you intend 
to prove it referring to C as an example of object-oriented paradigms? 
Really.



This makes absolutely no sense, as there's no reason why MoreExtendedClass
can't extend domain of ExtendedClass. However, for some reason it is
prohibited.


Not willing to understand the declaration idea will only block this
thread forever.


Please do not assume I disagree with you because I am unable to 
understand you. I understand you perfectly well and you are wrong. You 
are claiming that only way in OO to implement contacts is have the whole 
hierarchy enforce exactly the same function signatures based on 
non-extendable "declaration" and overriding functions must have exactly 
identical arguments, domains and signatures. This is plain wrong - 
domains can be extended and overriding functions can accept more than 
the base protocol requires (and also this protocol is not the same as C 
declaration). Obsessive insistence on formal "enforcement" without 
understanding why this enforcement exists and what purpose it was 
supposed to serve just makes lives of programmers in PHP harder because 
they have to work around something that was supposed to help them, but 
instead impedes them. PHP is not C, and blindly applying C concepts to 
PHP OO constructs would not work.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[Gustavo Lopes]

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 the signature
from abstract method definitions, as it's pointless then.


No it is not. The signature tells "this method would accept certain  
arguments". If you call it with these arguments, it would work. However,  
there's no promise to never extend the cases where it works - it goes  
contrary to the whole point of OOP to say "I will never loosen  
preconditions on my methods".


While this is true, we should be a bit pragmatic here.

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  
being the case) for arguments to be simply intentionally ignored. In fact,  
I don't know of any popular language that implements this type of  
contravariance. Plus, consider the case in which the superclass takes an  
argument by reference:


function increment(&$foo) { $foo = $foo + 1; }

It is obvious that in this case a subclass override that takes no  
arguments cannot possibly satisfy the contract of the original method.  
That is to say, by ref arguments are also used for postconditions.


That said, I think the only rules worth implementing are:

* Allow arguments with a supertype. For instance, this should give no  
warning:


http://www.php.net/unsub.php

Re: [PHP-DEV] __constructor parameter limitations.

[Pierre Joye]

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, but for some reason not for
> ctors, but fatal error for abstract ctors. Quite weird.
>
>> declaration, the implementation being done in the child class (bar
>> extends foo). This is the concept of 'abstract', see it like the
>> declaration and implementation in C. The PHP documentation is also
>
> No, it's not at all like declaration and implementation in C. In C,
> declaration and implementation relate to the SAME entity. In PHP, abstract
> method and its (multiple, inependent) implementations are different
> entities. Moreover, this is prohibited too:

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 basic of abstract
methods/classes.

> This makes absolutely no sense, as there's no reason why MoreExtendedClass
> can't extend domain of ExtendedClass. However, for some reason it is
> prohibited.

Not willing to understand the declaration idea will only block this
thread forever.


-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php