I hope I won't bother you with obvious things, but I think Stefan has
pointed out something important about LSB: the importance of the relative
access (like parent::), and the ambiguity of the context. It's not a problem
of static data.
Let me give an example, from my present real-life.

I am writing an ORM in PHP, and I really need LSB.
The principle is simple: to each table of the DB corresponds a class (a PHP
class). One table = one class. One column = one attribute.
All my PHP classes inherit from an abstract "base" class, who owns the main
abstract methods (of access to the DB, like selects, inserts, etc). The
structure of a table (which datatypes, keys, etc.) is represented through an
XML string, in a static variable, in the corresponding PHP class.
It is static because all the instances of a same class (= of a same table)
share the same structure of course; but it could be defined as not static as
well.

Now, let's say the "base" class is called "Entity".
And let's say I have an inherited class called "Client":

Abstract Class Entity {
        function read()
        {}
        function delete()
        {}
        ...
}

Class Client extends Entity
{
        public $id;
        public $first_name;
        public $last_name;
        static public $structure = "<? structure of Client ?>";
}

Now, imagine you are programming the "delete" function in class Entity.
And you have to use the $structure variable.
Since all the objects you are manipulating are "Client" objects (or other
inherited "table objects"), it would be logical to write:
parent::$structure
and not:
self::$structure, because Entity has no $structure variable.
The structures belong to the "table classes", not to Entity.
But "parent::$structure" has no meaning at compilation time in Entity.

There is no way for PHP to guess what you want to do: do you mean "now", or
do you mean "at run time"?
Personally, I think one should give the programmer the choice, exactly like
the programmer is given the choice between __CLASS__ (now, like it is
written steadily in the code) and get_parent_class() (at run time, like
objects are really instantiated).

I may be wrong, but I think LSB occurs every time you need to do something
in a RELATIVE way (get_parent_class(), parent::), because there is an
ambiguity upon what you consider as your reference, when you write something
like parent::$structure.
There relies the problem; it's not a question of static or not static. The
problem just frequently occurs with static variables.

Anyway, I do agree with Stanislav when he writes "I think we better spend
time on figuring out the concept".
And sorry for my commonplace prose. :)


Baptiste Autin
http://www.baptisteautin.com/


-----Original Message-----
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] 
Sent: jeudi 20 septembre 2007 20:58
To: Zoe Slattery
Cc: Dmitry Stogov; 'Marcus Boerger'; 'Lukas Kahwe Smith'; 'Michael Lively';
'Etienne Kneuss'; internals@lists.php.net; 'Andi Gutmans'
Subject: Re: [PHP-DEV] [patch] Late static bindings (LSB)

> How about writing the test cases first - and then the patch?

I'm fine with that - that's why I asking people for examples of what 
they want to do with it.
-- 
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]   http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


-----Original Message-----
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] 
Sent: jeudi 20 septembre 2007 20:58
To: Zoe Slattery
Cc: Dmitry Stogov; 'Marcus Boerger'; 'Lukas Kahwe Smith'; 'Michael Lively';
'Etienne Kneuss'; internals@lists.php.net; 'Andi Gutmans'
Subject: Re: [PHP-DEV] [patch] Late static bindings (LSB)

> How about writing the test cases first - and then the patch?

I'm fine with that - that's why I asking people for examples of what 
they want to do with it.
-- 
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]   http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to