Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:37719
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.200.168 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=GkjvILMpKqm7B8I3HpwQVnKn9WNXRfsZT2Rl0iB0NJu3IvwVvcDNHPuq8kmcvKfUdsL8RsTeAh1Al9Dia/DQnusHECjs10B5GftzySW9OgSU/dgWgBzRRXGnjjxaSI8H+YCgW+rXO5H2+XhJcEsvGrPZeHWVsmUz6+YQHWq+Rxg=
Message-ID: <10845a340805190602v26120ca9n26873bd6ed8e187@mail.gmail.com>
Date: Mon, 19 May 2008 14:02:03 +0100
Reply-To: RQuadling@GoogleMail.com
To: "Christian Schneider" <cschneid@cschneid.com>
Cc: "PHP Developers Mailing List" <internals@lists.php.net>
In-Reply-To: <483168E1.7090004@cschneid.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <48169695.9040803@omegavortex.net>
	 <1284376279.20080518132000@marcus-boerger.de>
	 <D4F13063-1E18-42B8-9B20-2FC0A4E0487C@cschneid.com>
	 <203770284.20080518184111@marcus-boerger.de>
	 <C4F1299D-F4B0-4F7E-A790-E1A358F37F83@cschneid.com>
	 <1082257838.20080518193053@marcus-boerger.de>
	 <1351350.20080518223746@marcus-boerger.de> <4830C61A.6020003@zend.com>
	 <10845a340805190155ha1f888bmf512862050bea02c@mail.gmail.com>
	 <483168E1.7090004@cschneid.com>
Subject: Re: [PHP-DEV] Class Properties in Interfaces?
From: rquadling@googlemail.com ("Richard Quadling")

2008/5/19 Christian Schneider <cschneid@cschneid.com>:
> Richard Quadling wrote:
>> (Not E_STRICT) If error_reporting does not include E_STRICT, then
>> unset()'ting properties defined in interfaces is allowed and operates
>> exactly as it does on normal variables and for properties defined in
>> classes. Whilst this may break the contract, this is what currently
>> happens and for the sake of BC (until a better solution is found), we
>> leave things alone. Personally, I think the potential new feature of
>> properties defined in interfaces should not be allowed to be unset.
>> But I'm looking at what I want with this and I hope that the following
>> text allows it.
>>
>> (E_STRICT) If error_reporting does include E_STRICT, then unset()'ting
>> properties defined in interfaces is not allowed and triggers an
>> E_STRICT error.
>
> We don't need this distinction: If you unset a property and access it
> afterwards you get an E_NOTICE so it can already be detected.
>
> And introducing different semantics depending on E_*-modes opens up
> another can of worms a la ini settings: Writing an application
> compatible with all different modes becomes a PITA.
>
> I agree with Stas here: Theoretical OO purism (I yet have to be shown
> code misbehaving with the current implementation) should not lead to
> artificial restrictions and/or code changes with BC breaks.
>
> - Chris
>

I'm no expert and I want to make a valid contribution here.

In trying to understand the proposal of allowing properties via
interfaces from your (Chris') point of view, what benefit do we get?

Allowing unset on properties in the class or in the interface, then
this seems like normal class properties.

We are talking about extending the behaviour of interfaces. Surely
this implies a greater amount of rigidity?


-- 
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"