Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55517
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 207.97.245.163 as permitted sender)
Message-ID: <4E770163.2090001@sugarcrm.com>
Date: Mon, 19 Sep 2011 01:46:27 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Pierre Joye <pierre.php@gmail.com>
CC: PHP internals <internals@lists.php.net>
References: <CAKUjMCXiYc63NKsUuYWXT-A-aPabdPV6142LP9h4-c=2aUxW=w@mail.gmail.com> <4E74E5A0.2030006@sugarcrm.com>	<alpine.DEB.2.02.1109181708480.3630@whisky> <4E76320F.6010904@sugarcrm.com> <CAF+90c8oZ4ghsFBa7jHtp_AKqD0N0cDhMycpjFTpCkLV9qRsqQ@mail.gmail.com> <4E764137.9080507@sugarcrm.com> <CAEZPtU6yBMP3X8_EpUXauDifAWEJwXS4fki5HtYNybWoCQ0kFw@mail.gmail.com> <4E7685DE.6010805@sugarcrm.com> <CAEZPtU6LvwM+qDCKQr+XOUu8Ab+QK2=hbkykD_d=jWiAwB8ozA@mail.gmail.com> <4E768C86.3030307@sugarcrm.com> <CAEZPtU4SONqYvAnj739-NdDYC=9DGkLrC=_cB-Ay6KJEbTpJZg@mail.gmail.com> <4E769418.6040200@sugarcrm.com> <CAEZPtU54b=aymn26V-xxHEm1Xb6MiSgvPC8By2+++MZyyDvJ7A@mail.gmail.com>
In-Reply-To: <CAEZPtU54b=aymn26V-xxHEm1Xb6MiSgvPC8By2+++MZyyDvJ7A@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] __constructor parameter limitations.
From: smalyshev@sugarcrm.com (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