Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29826
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: internals@lists.php.net,Mike Lively <m@digitalsandwich.com>
Message-ID: <46595406.8000401@mediawave.nl>
Date: Sun, 27 May 2007 11:48:54 +0200
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
CC: Ken Stanley <dohpaz@gmail.com>
References: <c70e053d0705261548v63c111a1qf9bfae78534b27da@mail.gmail.com> <4658D0CB.9070901@digitalsandwich.com>
In-Reply-To: <4658D0CB.9070901@digitalsandwich.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] late static binding (& $var::$static)
From: bart@mediawave.nl (Bart de Boer)


This subject has some correlation with my previous suggestion. Except I 
totally forgot about the "late static binding" discussion.

I'd like to give another real life example. This is an oversimplified 
version of what I'd currently like to do (without a bunch of workarounds):


<?php

class DataTableCollection {

	public function getItems() {

		$typeOff = this::$typeOf;
		$sql = 'SELECT * FROM ' . $typeOff::$tableName;
		...

		// or like suggested by Arnold Daniels:

		$sql = 'SELECT * FROM ' . ${this::$typeOf}::$tableName;
		...

	}

}

class DataTableItem {}



class Users extends DataTableCollection {

	static $typeOf = "User";

}

class User extends DataTableItem {

	static $tableName = "TBL_USERS";
	static $primaryKey = "USER_ID";
	static $foreignKeys = array('ADDRESS_ID' => 'Address');

}



$users = new Users();

foreach ($users as $user) {
	$user->doSomething();
}

?>


For this to work properly, you can imagine that it would need to be 
possible to dynamically access static variables all over the place from 
within different scopes. There are probably other approaches, but I 
thought this would be a very elegant one if it were possible. :)


-- Bart



Mike Lively wrote:
> Ken Stanley wrote:
>> I've been researching the current status of late static binding, and I 
>> came
>> across this mailing list with a few topics on this subject. After 
>> doing the
>> reading, I had a couple of questions that maybe one of the experienced
>> parties involved could help clear up for me. Basically, I am wondering if
>> anybody has tossed around the idea of having a scope of child::, just 
>> like
>> there is one of parent:: (for the class that is inherited from) and 
>> self::
>> (the current class). I understand that the idea has been discussed about
>> this:: or static::, but those two suggestions -- as fine as they are 
>> -- just
>> seem counter intuitive. this has always been used in the same context as
>> self::, but for instantiated objects, and static:: seems redundant (at 
>> least
>> to me). Is there a reason why this:: would be preferred over child::?
> It appears that all you are suggesting that is different from what has 
> been discussed previously is purely syntactical. In that regard I would 
> have to say that while neither this:: or static:: are jaw-droppers, 
> child:: seems somewhar counter-intuitive to me. From a purely semantical 
> standpoint, parent:: and self:: work because there is only ever one. On 
> the other hand it seems like it would be somewhat confusing to a 
> developer not aware of the syntax to figure out what child:: would mean. 
> A class could have 'n' number of children and while I realize that it is 
> not really what the late static binding is about it still seems awkward.
>> My second question on this topic would be how hard would it be to 
>> create a
>> child scope in the Zend Engine? Since I am not a very experienced C
>> programmer, this may be a naive question, but if Zend is smart enough to
>> know who the inherited class object is, could it be much more 
>> difficult to
>> know who did the inheriting?
> There is (with as much time as has passed this may be more accurately 
> represented as was) a working patch to implement late static binding. I 
> did some early work on it and it was then rewritten to store the 
> required information in the proper places. If I recall correctly it was 
> left at the point of someone needing to determine the performance impact 
> of the patch and come up with solid use cases.
>> I know it has been said by some that this functionality is rare, but I 
>> would
>> like to say that the functionality was just never needed until recently.
>> There are many cases that I can think of that this would be helpful, 
>> and if
>> need be, I would be more than happy to write more examples. I think,
>> however, that the above example shows a good situation for the parent 
>> class
>> to be able to see the child class.
> The term "late static binding" is slightly more rare than the 
> functionality itself. There are a few other languages that implement 
> similar concepts.
> 
> I do know the ball was left firmly in my court on this issue last year 
> and I also know that there has been continued interest from the php 
> userbase about such a feature. If there is still support for it among 
> the core developers I would be interested in taking up the issue again, 
> reviewing and ensuring the most recent patch is still adequate as it 
> relates to head, and determining the performance impact of the patch.
>