Proposal for Standards & Interface Repository

[ghurtado]

To emulate something like [level][easy] simply do key = "level.easy";

You may be able to emulate uniqueness of key, but you cannot emulate depth and hierarchy that way. What if I want to get back an array of all my levels?

$game['levels'][] = 'easy';
$game['levels'][] = 'medium';
$game['levels'][] = 'hard'; 

It is not using them as namespaces that I think is so useful about _get and _set, its the ability to use complex object hierarchies as though they were native PHP arrays, both for "setting" as well as for "getting".

(BTW, I am just assuming here that PHP5's _set and _get have the ability to cope with deep property access like above, I've never actually tested it)

[Selkirk]

Ghurtado, you can't chain property accesses if any but the last element in the chain results in a call to __set.

$obj->game->level = 10; // Does not work if the game property of obj is virtual.

With a setViaPath() method, you can.

illusina,
Here is an example of how I'm using this in WACT.

A fragment from the model:

class HangmanGame extends AttributeBasedDataSourceSupport {
    var $level 

A fragment from the controller:

$gameController->addParameter(new GetParameter('level', 'game.level')); 

The 'game.level' binds the input _GET parameter 'level' to the level property of the game object. SetViaPath() is useful in these input bindings.

[dagfinn]

Ghurtado, you can't chain property accesses if any but the last element in the chain results in a call to __set.

$obj->game->level = 10; // Does not work if the game property of obj is virtual.

I think you're wrong. I just tested it, and it seems to work.

[arborint]

Something like:

echo $data->getViaPath('levels.easy'); 

is no different than:

$data->levels['easy']; 

Actually I think that there is a big difference these to styles. The second assumes that 'levels' is an array, but the first makes no such assumption of how it is implemented internally. And I know from experience of building and using DataSpace containers that I want the ability to abstract it. It also could be something like:

$data->levels->easy;
// or
$data->context[$current]->levels['easy'];
// or
$data->find("SELECT * FROM levels WHERE difficulty='easy'"); 

[jayboots]

I should have code highligted the style I personally prefer, namely: $game->level->easy. That makes all access uniform and means that $game doesn't have to know how actually get to "easy" (or even know it is there) -- it only has to know about "level" which then surfaces "easy". Then again I vaguely recall running into a variation of this problem at some point:

you can't chain property accesses if any but the last element in the chain results in a call to __set.

but I'm afraid that I've experimented with so many styles recently that I have lost track of how it actually arose. oops.

There is clearly something to be said for dot-notation and I think it deserves more attention but since it isn't surfaced to the language I think it still represents a different type of overhead while looking a little bit artificial (not the dot-notation itself, just the fact that it is stringified and could require lots of knowledge in a top level object about lower level paths).

To beat the dynamic horse a bit more and as a possibly extreme example of intercepting, in one experiment I've virtualized all object behaviour by routing every magic method through __call which then dispatches through a held object (so the entire public interface of the object must be implemented virtually). This way it is possible to even virtualize the magic handling -- for example, I can have a stack of held objects and have __call dispatch to each in turn (or until bailout). Yet with a little bit of logic in __call I can change that behaviour at runtime by swapping in (or adding or removing or even ignoring) held dispatch objects. Behaviour is thus completely dynamic and intercepted calls (including all the property calls) see the container (and all of its virtual properties and methods). Parametric? Polymorphic? Why not? I wouldn't mention it as it is still a little sketchy and in all honesty I'm not really convinced it is entirely valuable compared to a more straight-forward approach (I had to write a function to pretty-up the backtrace as the indirection accumulates calls quickly) but the discussion seems to be lending itself in that way, at least at the moment . I can post a skeleton of one of the experiments if someone thinks it is interesting enough (well, I think that ghurtado might be interested).

I'm rambling so I think I should instead pause and take time to listen to and consider all the other points being raised in the discussion.

Greetings.

[dagfinn]

Is this the process that's supposed to take 500 million years? In that perspective, the fast pace of this thread seems not strictly necessary. Is someone trying to break the lightspeed barrier?

Seriously, this happens all the time in this forum. But my problem is that I prefer to think about large design issues for a while before responding. But it's hardly possible here, so let me just put down a couple of the ideas that occur to me.

Marcus is right. Keeping the ambition level down is critical. It might be more realistic to have slow convergence of frameworks in the direction of similar interfaces rather than some "standard" that everyone will be expected to follow. The discussion that's going on here is meaningful anyway of course.

I'm thinking in terms of Eric Evans' Domain-Driven Design. The book uses the concept of "knowledge-rich design". It occurs to me that the knowledge in a technical software domain can be as difficult to get at as the knowledge in a non-software domain (cargo shipping is one of Evans' examples). As Marcus points out, there are few experienced framework developmers.

Then there's another concept from Evans: refactoring to deeper insight. How do we know that the conceptual model embodied in a set of interfaces is stable enough to survive over time without preventing refactoring to deeper insight?

Selkirk's template example is illuminating: it's not just about flexibility, it's also about the fact that a standard template engine has a least three different responsibilities: keeping data, combining the data with the actual template, and handling files. So it's conceptual as well as technical.

This may be too philosophical, at least for those who haven't read Evans. I hope it makes sense.

[dagfinn]

How about applying the Tracer Bullet principle to the whole idea? Define a single interface (or a small set for one purpose) and try to make a couple of frameworks interoperate by using it before going any further in defining "standards"? Proof of concept.

[chiefmonkey]

I would certainly be interested in helping, although I have more of a Java background than PHP (that may help or be a hinderance)

George

[dbevfat]

How about applying the Tracer Bullet principle to the whole idea? Define a single interface (or a small set for one purpose) and try to make a couple of frameworks interoperate by using it before going any further in defining "standards"? Proof of concept.

This could be very interesting. And the DataSource interface is just the place to start, I believe. Could be adapted to frameworks like Mojavi and Wact, and on the other hand to template engines like Smarty.

I'll start:

interface DataSource
{
} 

j/k

I am serious about this being a good idea, though.

[DougBTX]

convergence of frameworks

Has anyone made a list of common functionality between the PHP frameworks in question?

See what we want to do in each framework, then work out how we want to do them.

Douglas

[Travis S]

To beat the dynamic horse a bit more and as a possibly extreme example of intercepting, in one experiment I've virtualized all object behaviour by routing every magic method through __call which then dispatches through a held object (so the entire public interface of the object must be implemented virtually).

Two things, completely off-topic... First, isn't that like a Mock of sorts? Second, why not just use DI or some home grown manager and swap out the objects before you load them? That seems like very dangerous water to be treading on...


Back on topic... I didn't think you could chain together __get() methods, but I was wrong:

class A {
    public function __get($key) { return $this->$key; }
    public function __set($key, $value) { $this->$key = $value; }
}

$a = new A();
$b = new A();
$b->txt = "Hello World!\n";
$a->b = $b;
echo $a->b->txt; 

Works just look you'd expect. And apparently, they have been adjusted (as of 5.0.4 to allow you to use array access as well. If you hide txt in an array (associate or numeric) you can pull it out. This was actually one of my stumbling blocks with using the magic methods - I distinctly remember arrays choking on them at some point in the past. Maybe I was thinking of __call().


Ok - so what do we want to name this? I've seen DataSpace, DataSource (which to me implies that it knows how to set itself up), Node (which implies others to me, probably by virtue of the way I've worked with it), ValueContainer, Values, ComonentValues... did I miss any? I think it's far to say that if there's a common name out there we can latch onto, that much the better as people will more easily recognize it. Another thing to keep in mind is name collisions.

[lastcraft]

Hi...

Regarding the tracer bullet comment from dagfinn, that is my thinking as well. I think a Properties/Map/KeyValues class is a good test of the feasability of a project. After all, if you cannot standardise a configuration file or a database row, the project is dead in the water.

Sorry Jeff, but I think the following is your fault...

Your simple starting interface has suddenly grown into something that can be dropped in to a template. This is a hell of a complex problem and massive feature creep. You can drop any data structure into a template . You are going to have an inteface for any data structure? There already is one, it's called XSchema. Still want one?

Also the performance argument is a bit lame for dictating the interface. If you want something fast than just add an asHash() method (you'll need one anyway) and then do the key look-up on the resulting array. Do that within a dynamic proxy (Travis - that was the pattern you were after) to get member access if you want performace. If you eschew method look-ups then you break reflection and you won't have any methods for your interface to enforce anyway.

Another thing missing is the clone behaviour. Whilst making this object a value object makes sense for simple strings, it's basically a container, You would expect shallow copy behaviour just like an array.

Anyway, back to tracer bullet. How about the standard defines just the KeyIndexed interface (hint hint) and we get to see it in the next version of WACT, Mojavi and Changes?

yours, Marcus

p.s. Chained lookup using __get() works fine in PHP5 (I haven't tried setting properties), but depending on your version of PHP4 can actually cause a spectacular crash. The [] (array emulation) behaviour is spotty and buggy, but I havent tried it in PHP5.1 yet. I don't trust it though given Zend's track record.

p.p.s. Suggest KeyValues, KeyIndexed, KeyLookup, Keyed (I like that one) or Properties. "DataSource" and "DataSpace" say zilch and are more on the implementation side anyway.

[ahundiak]

Figuring out names that are acceptable to everyone seems to be an exercise in futility. Why not abstract the names themselves like the drug companies do? Pick a theme such as Lord of the Rings and start using characters. So DataSource becomes Frodo.

[Travis S]

Do that within a dynamic proxy (Travis - that was the pattern you were after) to get member access if you want performace.

Of course... Thanks.

p.p.s. Suggest KeyValues, KeyIndexed, KeyLookup, Keyed (I like that one) or Properties. "DataSource" and "DataSpace" say zilch and are more on the implementation side anyway.

Agreed on the last point. They seem to carry an awful lot of implied baggage to me.

I don't see where you're going with Key* though? I'm thinking ValueProxy and MutableValueProxy. Explains exactly what it is and what it does. Thoughts?

I just set up an SVN server @ https://svn.opensir.org/svn/. I've also added a first draft of the ValueProxy and MutableValueProxy interfaces (which are still mobile with svn mv if another name comes up). If anyone wants write access to the trunk, PM me and I'll get it set up.

[Selkirk]

I think you're wrong. I just tested it, and it seems to work.

class testMe {
    public function __set($name, $value) {
    }
}
$test = new TestMe();
$test->blah->blah = FALSE; 

Fatal error: Cannot access undefined property for object with overloaded property access

[Selkirk]

Anyway, back to tracer bullet. How about the standard defines just the KeyIndexed interface (hint hint) and we get to see it in the next version of WACT, Mojavi and Changes?

I agree. We need to prove we can come to a conclusion in one area before tackling others.

So can we all agree on this:

interface Properties {
    public function __get($property);
    public function __set($property, $value);
    public function __isset($property);
    public function __unset($property);
} 

I will also need Path access (at least for now). I don't sense general agreement on this, but thats ok. It can be something WACT specific:

interface StructuredProperties extends Properties {
    public function getViaPath($path);
    public function setViaPath($path, $value);
    public function hasPath($property);
    public function unsetViaPath($path);
} 

I will also need meta data for the properties. I think this is an area where will can also reach consensus. This is important for tool interoperability.

interface PropertyInfo {
} 

Can we agree to keep the meta data interfaces separate from the Properties interface, leaving Properties as just the magic methods?

[Selkirk]

So DataSource becomes Frodo.

A new hire actually bragged to me once that he used this method to name his variables. We fired him shortly after.

So here is the new interface:

class BewareTheJabberwock extends my_son {
    function TheJawsThatBite();
    function TheClawsThatCatch();
    function BewareTheJubjubBird();
    function ShunTheFumiousBandersnatch();
} 

[lastcraft]

Hi...

I don't see where you're going with Key* though? I'm thinking ValueProxy and MutableValueProxy. Explains exactly what it is and what it does. Thoughts?

No it doesn't, it describes an imlementation. Here is the context...

class DataSpace implements KeyLookup { ... } 

It has to read well as part of an implements line...

class DataSpace implements Keyed { ... }
class DataSpace implements KeyValues { ... }
class DataSpace implements KeyIndexed { ... } 

See what I mean?

By the way, your post earlier about a read only interface won't work without a lot of machinations. For example, say you have this...

interface Gettable { }
interface SettableAndGettable implements Gettable { } 

No matter which one you type hint with, you have not enforced read only behaviour.

You would have to have...

interface Gettable { }
interface Settable {}
class SomethingSettableAndGettable implements Gettable, Settable { } 

It really isn't worth the effort is it? Especially when you can all too easily hack around PHP to get what you want anyway. I don't think it's worth it.

Regarding your template droppable version, that should be called Templateable...

class Person implements Templateable { ... } 

Keeps it separate from Keyed and emphasizes what a very specialist interface it is.

yours, Marcus

[Selkirk]

And apparently, they have been adjusted (as of 5.0.4 to allow you to use array access as well. If you hide txt in an array (associate or numeric) you can pull it out.

So this works in 5.0.4?
echo array('key'=>'value')->key;

[jayboots]

class testMe {
      public function __set($name, $value) {
      }
  }
  $test = new TestMe();
  $test->blah->blah = FALSE; 

Fatal error: Cannot access undefined property for object with overloaded property access

We can code around these problems by supplying some real implementation:

class TestMe {
     private $vars = array();
     public function __get($name) {
         if (isset($this->vars[$name])) {
             return $this->vars[$name];
         } else if ($name == 'blah') {
             $this->vars[$name] = new StdClass;
             return $this->vars[$name];
         }
     }    
     public function __set($name, $value) {
         if ($name=='blah') {
             $this->vars[$name] = new StdClass;
         } else {
             $this->vars[$name] = $value;
         }
 
     }
 }
 $test = new TestMe();
 $test->blah->blah = 'foo';
 echo $test->blah->blah;  // result: foo 

Of course, the implementation should be generalized -- here I just want to show that it should be possible to avoid snafus. I only tested on 5.1RC1. I don't see the point in targetting anything earlier.

[lastcraft]

Hi...

I will also need Path access (at least for now). I don't sense general agreement on this, but thats ok. It can be something WACT specific:

Possibly called Hiearchical?

yours, Marcus

[Travis S]

It has to read well as part of an implements line...

class DataSpace implements Keyed { ... }
class DataSpace implements KeyValues { ... }
class DataSpace implements KeyIndexed { ... } 

See what I mean?

Ok... You're working from the point of view that interfaces should answer the question "Is ...?", correct? Makes sense and should help avoid naming collisions.

edit - changed "Is a...?" to "Is...?"

By the way, your post earlier about a read only interface won't work without a lot of machinations. For example, say you have this...

interface Gettable { }
interface SettableAndGettable implements Gettable { } 

No matter which one you type hint with, you have not enforced read only behaviour.

Hmm... I'm going to disagree here, though it wouldn't be the first time I've been wrong.

class MySpecialObject {
    function readSomeValue(Gettable $values) {
        // do something reading wise
    }
} 

With that I'm asking for at least Gettable. If I get something more, thats fine, but I'm defining that all readSomeValue() needs to have access to is get(). Am I missing something?

[Travis S]

I agree. We need to prove we can come to a conclusion in one area before tackling others.

So can we all agree on this:

interface Properties {
    public function __get($property);
    public function __set($property, $value);
    public function __isset($property);
    public function __unset($property);
} 

So we're back to magic methods?

I would adjust them to:

interface Properties {
    public function __get($name);
    public function __set($name, $value);
    public function __isset($name);
    public function __unset($name);
} 

Minor thing, but it sticks with the manual's definition of them.


That said - it seems to me there might be a high name collision rate with Properties. NamedProperties, KeyedProperties, IndexedProperties? No - strike the last, it implies $properties->value[1]->subvalue[2]->etc.

[jayboots]

fwiw: I like $key, $value mainly because it implies a lookup.

[arborint]

So we're back to magic methods?

I would adjust them to:

interface Properties {
    public function __get($name);
    public function __set($name, $value);
    public function __isset($name);
    public function __unset($name);
} 

While I agree with the magic methods I think it is ignoring reality to not have get() and set(), so:

interface Properties {
    public function get($name);
    public function set($name, $value);
    public function propertytIsSet($name);  // ? name
    public function propertyUnSet($name);  // ? name
    public function __get($name);
    public function __set($name, $value);
    public function __isset($name);
    public function __unset($name);
}