Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:21660
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Mon, 23 Jan 2006 20:27:55 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <101671748.20060123202755@marcus-boerger.de>
To: Andi Gutmans <andi@zend.com>,
	Sebastian Bergmann <sb@sebastian-bergmann.de>
Cc: internals@lists.php.net
In-Reply-To: <dr23tq$bub$1@sea.gmane.org>
References: <1179437188.20060122193218@marcus-boerger.de>
	<7.0.0.16.2.20060122185859.02b91f38@zend.com> <43D48EEB.1090808@php.net>
	<dr23tq$bub$1@sea.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Static vs. non static
From: helly@php.net (Marcus Boerger)

Hello Andi, Sebastian,

Monday, January 23, 2006, 9:25:29 AM, Sebastian wrote:

> Lukas Smith schrieb:
>> If I get Marcus proposal properly he would then allow changing things 
>> from:
>> parent::method();
>> 
>> to
>> 
>> parent->method();

>  If that is the case, then it would be consistent to allow

>    this->method()
>    this->attribute
>    parent->attribute

parent->method() would work
attributes are more than discussable and i don'T think we need anything
more than $this->attibute for dynamic attibutes. And since you cannot
overload protected or public attibutes or hide base class attibutes there
is no need to provide a means of skipping hierarchy levels.

If i was very pedantic i'd not propose 'baseclass->method()' but the
formal correct '$this->baseclass::method()'. However i see the former as
a very handy and clear shortcut. Another reason to go with the shortcut
is that once we'd allow '$this->baseclass::method()' people would start
to ask for '$obj->classname::method()' which is at somepoints usefull
but is not exactly the KISS approach.

Best regards,
 Marcus