Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26324
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain php.net from 81.169.182.136 cause and error)
Date: Sat, 4 Nov 2006 19:05:02 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <702235698.20061104190502@marcus-boerger.de>
To: Christian Schneider <cschneid@cschneid.com>
Cc: Marcus Boerger <helly@php.net>,
	Ilia Alshanetsky <ilia@prohost.org>, Zeev Suraski <zeev@zend.com>,
	php internals LIST <internals@lists.php.net>
In-Reply-To: <454CBC2C.8020204@cschneid.com>
References: <A302A34A-2257-447B-A2A0-CD665F80DC47@prohost.org> <7.0.1.0.2.20061024085428.053f9cf8@zend.com> <F2137416-B788-4C8F-80C5-FEC0AFCD31D2@prohost.org> <7f3ed2c30610240757v28702861r8d5f22f7e3047e60@mail.gmail.com> <7.0.1.0.2.20061024170856.0583dd20@zend.com> <E5728B60-0A7E-4E46-93AC-103A82CE44BD@prohost.org> <1838975922.20061024205524@marcus-boerger.de> <71B5B01C-EDC5-46B0-8747-0706B2C7DF1F@prohost.org> <454B60E8.8010305@cschneid.com> <1227362691.20061103191138@marcus-boerger.de> <454CBC2C.8020204@cschneid.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Why 5.2 should not be delayed for E_DEPRECATED
From: helly@php.net (Marcus Boerger)

Hello Christian,

Saturday, November 4, 2006, 5:13:32 PM, you wrote:

> Marcus Boerger wrote:
>>   Liskov applies to static methods as soon as calls via objects are common
>> which is true for PHP. 

> This is common in PHP and you consider this good practice? Interesting, 
> wasn't what I would have expected...

I didn't say it is good practice, god behave :-)

>> In PHP it might work as
>> expected but then all programmers that come from langiages like C++ get
>> confused.

> I didn't realized how big an impact C++ has on the PHP design. Allow me 
> to *shudder*, I'm glad we're only talking E_STRICT here (-:C

Pretty long explanation but I hope it clearifies how I was answering:
Language developers copy from each other. Copy in the sense of looking
at the ideas and experience from others and taking them over, in a
fashion that suites their own language. As PHP has a C like syntax and
also some C semantics it goes in a pool with languages like C, C++, C#,
ObjC, Java and a few more. It also has influence from Perl or Delphi.
Looking at the object model we have, it is a combination of influences
from C++, Java and Delphi plus lately also C#. Plus stuff I cannot even
specify a counterpart for, maybe some of Python. So when I mention C++
here, I am refering to a specific piece of behavior that can best be
found in C++. And I would do the same for other parts with the help of
other Languages. I do so becasue I consider that most people prefer an
explantion by example over a theoretical explanation - in that case I
can suggest nice books:
- Object-Oriented Type Systems by Jens Palsberg and Michael I Schwartzbach
  http://www.amazon.com/Object-Oriented-Type-Systems-Jens-Palsberg/dp/047194128X/sr=1-1/qid=1162662320/ref=sr_1_1/002-5762121-6939211?ie=UTF8&s=books
- A Theory of Object by Martin Abadi and Luca Cardelli
  http://www.amazon.com/Theory-Objects-Monographs-Computer-Science/dp/0387947752/sr=1-1/qid=1162662574/ref=sr_1_1/002-5762121-6939211?ie=UTF8&s=books
Actually the first book is pretty easy and can get anybody started. The
second is a pretty mathematical approach. That is very good, since it
shows what you can do and what not and can explain why certain things
are not working. But in PHP we don't respect much of the rules. Unless
E_STRICT is active, which gets the most imortant ones. Luca Cardelli
wrote more about the Lambda Calculus but I haven't read them since the
book above captures all that's needed.

>> However the point of adding E_DEPRECATED is still open. Where open only
>> means which version will first have it. From my perspective that will be
>> either 5.3.0 or 6.0.0 depending on whetever comes out first. Helping here
>> would be greatly appreciated.

> What help is needed, compiling the list of E_NOTICE/E_STRICT to be 
> convert to E_DEPRECATED? Or giving input on how to convert the 
> individual messages? I'm willing to help.

Yes such a list would be very helpfull. If you think individual messages
need to be altered other then changing the severity than we might need to
discuss that as well. Having the list of such messages would help anyway.
Because without helpfull feedback we can never get rid of design flaws.
Looking forward to get that list.

best regards
marcus