Proposal for Standards & Interface Repository

[arborint]

So which makes more sense?

return $this->__get('width') * $this->__get('length');
// or
return $this->get('width') * $this->get('length');
// or your internal storage
return $this->_width * $this->_length;
// or mine internal storage
return $this->_corral['width'] * $this->_corral['length']; 

The one you didn't have to explain what it was.

[illusina]

Hello everyone,

Following the thread again. And again amazed at how much people can go in circles. I suppose what puzzles me is why, in a thread about an application code repository, we're discussing the semantics of magical overload operators. While the __get/__set discussion is valid, I don't believe that _this_ is the place for it.

@Travis: I've been browsing around your phpCR -- it looks interesting, what is your reason for wanting to set it aside in favor of this? More popular support, or...?

@Selkirk: Do you think we can come to a reasonable conclusion regarding a "Properties" interface? Having set()/get() are going to be mandatory, in my opinion, simply because they are exposed and accessible.

Now that I think about it, perhaps this thread should fork into get/set and Application Code Reposistory. Thoughts?

Regards,

Tyler Tompkins

[ghurtado]

Now that I think about it, perhaps this thread should fork into get/set and Application Code Reposistory. Thoughts?

You are probably right, I think this thread went way off-topic a few pages ago.

[Travis S]

illusina: Thanks - I think phpCR is interesting and has a lot of potential too. My intent with this is to bring phpCR into its own as a PHP interface library by making the adjustments that might seem necessary to move it into a PHP realm. Whether they are needed, or even a good thing, I've yet to determine. As this conversation continues in circles though, I don't know that changing it with a concensus is going to be possible - yet. Hopefully we can settle on one interface soon as see how well it works into several frameworks. If we can get our feet wet with a few smaller interfaces, maybe in time we'll be able to figure out what needs to be done for a full fledged content repository.

[lastcraft]

Hi.

If you amke the effort to follow it, it's not going circles. It's most definitely on topic, because if this problem cannot be solved, then neither can any other. Forking the thread will just trash the thread as it finally makes progress. The reasoning is:

1) We want standard interfaces
2) To be standard people actually have to use them
3) This means they must work with the majority of code
4) Writing interfaces is thus hard
5) Can we prove that the project is feasible with just one
6) Let's try it with a KeyValues interface
7) Oh dear it's more complicated than we thought, but let's battle through.

If this argument cannot be followed in a single thread then the competency to write an interface library is just not there. It's freakin' intense and you have to get your hands really dirty.

yours, Marcus

[Sgarissta]

I'm going to re-iterate something Marcus hinted at earlier. Designing an interface is nearly impossible. Abstracting an interface out of existing implementations is much easier. Instead of trying to come up with an interface in isolation, why not go find the places in the major frameworks or libraries that these sorts of things are being done, and find the common ground?

I realize that a lot of the proposed interfaces may not be in common use, but I think taking a set of implementations and dissecting the common bits out is going to be a lot moe productive, faster, than the current method. Surely a simple Values object like we're looking at right now has been used before, several times. It's easier to see the potential implementation 'gotchas' when there are already implementations to look at.

[Selkirk]

@Selkirk: Do you think we can come to a reasonable conclusion regarding a "Properties" interface? Having set()/get() are going to be mandatory, in my opinion, simply because they are exposed and accessible.

I am fine with having a set()/get().

I would like to see __set()/__get() as well, but I think I've made all the arguments that I can in favor of that.

For this to work, we all have to get used to the idea that no perfect solution for this is possible in PHP. Until PHP implements a "real" property mechanism with support for getters and setters and reflection as part of the language, anything we do with "virtual" properties is going to have a few warts.

We should also discuss the Java style getXXX() and setXXX().

[arborint]

I agree with illusina that get()/set() are necessary because that's how everyone does it currently. The question of how we want people to do it in the future determines whether and how we add __set()/__get() or getXXX() and setXXX().

I would like to comment about the design process in this forum because I know it can feel like we are going in circles. Unlike most projects where there is a lead and a group of likeminded people, this process is decidedly democratic and therefore slower and messier. But the thing I have found from going through this a couple times is that it is very rewarding in hindsight because the market of ideas gives a much richer basis for going forward. However we do need to acknowledge that this process makes getting a complete design difficult in one pass (which is probably not a bad thing).

So I would propose that we acknowledge what we know and what we don't know, agree on what we agree on and push what we don't down the road, go off and implement something to see what the reality of our decisions is, then come back and "circle" again. It sounds rather Scrum like.

[illusina]

Hi.

If you amke the effort to follow it, it's not going circles. It's most definitely on topic, because if this problem cannot be solved, then neither can any other. Forking the thread will just trash the thread as it finally makes progress. The reasoning is:

1) We want standard interfaces
2) To be standard people actually have to use them
3) This means they must work with the majority of code
4) Writing interfaces is thus hard
5) Can we prove that the project is feasible with just one
6) Let's try it with a KeyValues interface
7) Oh dear it's more complicated than we thought, but let's battle through.

If this argument cannot be followed in a single thread then the competency to write an interface library is just not there. It's freakin' intense and you have to get your hands really dirty.

yours, Marcus

@Marcus: I don't know you very well, so I don't know if I offended you with my comment. If I did, apologies. Anyways, good point regarding the need for redundant reinteration . I know that it does go somewhere, but I simply feel that this thread would be better focused on goals and intentions rather than implementation (so that, rather than having two parallel threads within one, we can have one go and discuss one matter, and another another matter).

@Marcus: I didn't catch what the KeyedValues interface was. Simply another name for a "Properties" interface?

why not go find the places in the major frameworks or libraries that these sorts of things are being done, and find the common ground?

This is a point I'm struggling with myself. To quote a note I wrote to myself: "framework integration is a possible application, but not the goal". That's how I feel about this project. It shouldn't be about integrating frameworks, it should be about integrating code. Any code, small large and something between. Only that, a series of interfaces with reference implementations. Given this, I suppose that only way to really _test_ the ideas would be the route Marcus et al have already taken -- reference implementation through frameworks. Is there another way?

Unlike most projects where there is a lead and a group of likeminded people, this process is decidedly democratic and therefore slower and messier.

Great point.

For this to work, we all have to get used to the idea that no perfect solution for this is possible in PHP. Until PHP implements a "real" property mechanism with support for getters and setters and reflection as part of the language, anything we do with "virtual" properties is going to have a few warts.

And therefore we should use the strengths of PHP as a dynamic language. /me ques jayboots

Regards,

Tyler Tompkins

[lastcraft]

Hi...

@Marcus: I don't know you very well, so I don't know if I offended you with my comment.

Not at all . Sorry, I was just typing very hastily in an attempt to head off a thread fork. I think forking would have been a disaster. Some of the most productive threads on SitePoint have been long ones.

I know that it does go somewhere, but I simply feel that this thread would be better focused on goals and intentions rather than implementation (so that, rather than having two parallel threads within one, we can have one go and discuss one matter, and another another matter).

I say let it roll for a bit and see if one interface can be born. I suspect another 100 posts whilst the get() interface is explored.

We haven't worked out an SP etiquette for posting abstracts at the top of posts to allow people to skip the stuff they are not interested in. Hmm...another social software project is born...

@Marcus: I didn't catch what the KeyedValues interface was. Simply another name for a "Properties" interface?

Yeah. I am still tossing the names around to see which one sticks.

...it should be about integrating code. Any code, small large and something between. Only that, a series of interfaces with reference implementations.

Agreed. Things like Reader, Writer, etc. Java like, but I find myself using them all the time. Another area of commonality is HTTP stuff. The PEAR stuff and SimpleTest are close at the top level of this stuff: Url, HttpRequest, HttpResponse (ST is much more finely subdivided, but that is more the level of debugging information required of a test tool).

Regarding Properties/KeyValues/Keyed there are a host of libraries to look at and just about every interface seems to be used: PEAR:: DB, PEAR:: DB_DataObject, Changes, Wact persistence, Propel, Wact Dataspace, J2EE properties, etc, etc.

Given this, I suppose that only way to really _test_ the ideas would be the route Marcus et al have already taken -- reference implementation through frameworks. Is there another way?

It is a safe way. The C++ standard evolves this way, with draft ideas being picked up by compiler writers some years before the final standard. And Boost is often a reference implementation (it's heavily influenced TR1).

If you are not using C++ this won't mean a whole lot . Basically Boost is an exquisitely written small class library. A boost for PHP would be a wonderful thing (sigh).

yours, Marcus

[arborint]

We have the peers. We just need to keep things going at the review part.

So:

get()/set()?

__get()/__set()?

getXxx()/setXxx()?

What's in for the first pass? For example the Skeleton code is very basic and only uses get()/set(). What is a common minimum that WACT or Mojavi would use?

[Brenden Vickery]

get()/set()?
__get()/__set()?
getXxx()/setXxx()?

Thought Id throw in my 2 cents.

__get()/__set() is a non starter for me. I really dislike the use of this for many of the reasons already mentioned.

By get()/set() I assume you mean get('propertyName')/set('propertyName, 'value')? Im not a fan of this either. When comparing an interface like this to a get*()/set*('value') interface, like Fowler says, its about comparing an implicit interface to an explicit interface. Using the implicit interface, you have to look into the code to figure out how to do something (eg. How do I get the id of this User? Do I type get('id') or get('userId')?) Using an explicit Interface getting the Id is made obvious by the interface of the class because it has a getIdentity() method.

There are other disadvantages that come up in common situations using the get()/set() interface.

That said Im not even sure what types of objects youre expecting to impliment this interface. Depending on the answer to that question I might change my mind. I guess what Im saying is that both styles have advantages depending on their use. Maybe two seperate interfaces?

Could someone explain what value I would get out of using a framework that implemented these interfaces? Or what value a framework gets from implementing these interfaces? Sorry if this was covered, but this isnt immediately obvious to me.

[illusina]

We have the peers. We just need to keep things going at the review part.

So:

get()/set()?

__get()/__set()?

getXxx()/setXxx()?

What's in for the first pass? For example the Skeleton code is very basic and only uses get()/set(). What is a common minimum that WACT or Mojavi would use?

Ahh - would or do ? As of this moment, Mojavi 3.0.0-DEV -- a framework that was written by my predecessor -- uses a single convention in two implementations for get/set operations. Within the Request class, for example, there is a getParameter/setParameter method battery Request also has a getAttribute/setAttribute method battery for IMC (inter module communication).

Now, regarding which one I would use...

Firstly, it should be noted that I'm taking this from a composition based design perspective. That is, my classes that use a Properties-implementation object or what-have-you will be composed of said object. They will not, for all the power within me, extend this a Properties-implementation class. Mojavi 3 was designed such that numerous classes extended from base "ParameterHolder" class, which provided all the setParameters/getParameters methods for numerous classes. Now, while this design choice worked, I have a great distaste for this sort of design manuevering. If an object is going to extend/inherit something, it should _be_ one of those somethings.

Now, since I'm approaching this from a composition perspective, it might be useful to show why a simple set/get might be a bad idea.

Let's say I have one Properties-implementation object composed into a Request object (for example). To address these, I might take the route of taking __call() and facading unknown methods calls to the inner Properties-implementation object. Now, if I wanted to add a second object to be composed, I would have to invent some sort of a regex to determine which of the two inner Properties-implementation objects I want to talk to. For example:

// .........
$obj = new SomeObject($propObj1, $propObj2)

// $obj is my __call enabled object composed of two other objects
$obj->setAttribute('somekey', 'some value');

$value = $obj->getParameter('somekey'); // error, no param

// ........ 

Just to be a tad more verbose: What this $obj class' __call function would be doing is routing all getAttribute/setAttribute calls to say $propObj1, and all getParameter/setParameter calls to $propObj2.

In closing, I feel it would be useful to keep in mind that composition based design is also an option for these objects.

Time for dinner!

Regards,

Tyler Tompkins

[arborint]

For our reference, here are the internal "interfaces" of the options:

void set ( string name, mixed value )
mixed get ( string name )

void __set ( string name, mixed value )
mixed __get ( string name )

mixed __call ( string name, array arguments )

From that I assume that you could implement get()/set() and have __get()/__set() call it (or vice versa) so implementing both is trivial.

__call would require both a naming convention and some string ops on the name.

[dagfinn]

It's most definitely on topic, because if this problem cannot be solved, then neither can any other.

Well...this problem is very limited in a certain technical sense, but it's non-trivial because of the large number of different contexts in which it will be used.

How about something specialized and yet simple like an interface for a URL object? Java already has that in the standard library. I haven't seen anything with a reasonable interface in PHP.

I don't want to derail the ongoing discussion; just consider it.

[lastcraft]

Hi.

I'd have preferred to go down this route (mor espcialised role). Frankly Java has only started adding interface libraries after already having a class library. Building a lower level class library makes more sense to me. However, right now I don't want to derail an ongoing discussion.

So what is a Properties class (or KeyValues interface) used for? Database row, configuration, and what else?

yours, Marcus

[mx2k]

components.

[sweatje]

So what is a Properties class (or KeyValues interface) used for? Database row, configuration, and what else?

Proxy for request/environment values

[jayboots]

So what is a Properties class (or KeyValues interface) used for? Database row, configuration, and what else?

uhh... anytime you need to provide rule based access to public values as opposed to direct, unchecked access. Anytime you want to anonymously hook access to other layers. In other words, for everything worth doing

[lastcraft]

Hi...

Random thoughts then:

So typical usage is like this...

class Request implements Properties { ... }
class Row implements Properties { ... }
class Configuration implements Properties { ... }
class Session implements Properties { ... } 

All of these are fixed key sets (no need for unset()). All contain values or serialised objects, not object references, so cloning will be required. Only half would need a read only interface, possibly none. Three quarters are saveable, but that's a different interface. All could have spaces and other punctuation in their key names.

Apart from caching mechanisms, I cannot see any need to decorate these objects or to proxy them further. They all seem pretty dead end value objects to me.

The following all look fine to me...

$memento = $session->get('thing');
$memento = $session['thing'];
$memento = $session->getThing();

$field = $row->thing;
$field = $row['thing'];
$field = $row->get('thing');

$setting = $configuration->get('thing');
$setting = $configuration->getThing();
$setting = $configuration['thing'];

$parameter = $request->get('thing');
$parameter = $request['thing']; 

...whereas the other combinations are a little alien, but maybe that's just me.

The accessor syntax (methods) and member syntax (__get()) have the problem that property keys are limited. I am swinging around to the square bracket syntax, but I bet there are a whole host of implementation problems with that. The simple get($name) syntax has the least problems, although it's not very exciting.

For testing the simplest is the array syntax (square brackets), because you can simply drop in a hash. As these classes are value objects though, I don't see any pressing need to mock these classes. Just pass in a bare Properties class instead (note the nameclash, the interface should be called something else).

It seems that the constraints on this interface are not so tight after all, at least for the examples proposed so far.

yours, Marcus

[mx2k]

$setting = $configuration->get('thing');
$setting = $configuration->getThing();
$setting = $configuration['thing']; 

now are you all still talking about class properties still or are we using this interface to do other things like pull from an array/list of configuration settings and are there virtual properties being created for the configuration values and such?

$settings = $configuration->get('items');
$settings = $configuration->getItems; 
$settings = $configuration->Items;
$settings = $configuration; //$configuration is the array

// 
$settings = $configuration->get('items');
$setting = $settings['Thing'];

$setting = $configuration->getItem('Thing');
$setting = $configuration->Items['Thing']; 
$setting = $configuration['Thing']; 

$parameter = $request->Item('email'); 
$parameter = $request->getItem('email'); 
$parameter = $request->items->get('email'); 

[arborint]

And for set:

$configuration->set('Thing', $setting);
$configuration->setThing($setting);
$configuration->Thing = $setting;
$configuration['Thing'] = $setting;           // needs SPL I assume 

I have not done enough with the magic/overloading functions or SPL to know the nuances and possiblities.

And what about path access?

$configuration->set('Items/Thing', $setting);
$configuration->setItem_Thing($setting);     // or some naming convention
// but
$configuration->Items->Thing = $setting;
$configuration['Items']['Thing'] = $setting;  // SPL ?
$configuration->Items['Thing'] = $setting;   // does this work with __set()? 

How do we escape that scripting languages like PHP traditionally do a lot of tricks with string manipulation?

[Dr Livingston]

$configuration['Thing'] = $setting;           // needs SPL I assume 

Yes, you can treat an object as an array, and you need PHP5. This is why I think it was also proposed, and it makes sense really.

[Travis S]

And for set:

$configuration->set('Thing', $setting);
$configuration->setThing($setting);
$configuration->Thing = $setting;
$configuration['Thing'] = $setting;           // needs SPL I assume 

I have not done enough with the magic/overloading functions or SPL to know the nuances and possiblities.

All of these are possible, but the last I'm against. Changing the behavior of an object via magic methods is ok, but changing the behavior of an internal type leads down a road that I think has a lot of boogie men waying to jump out and beat you up. Seriously, what's next, IntObject in which you can treat an object as an int? You can already sort of do with __toString() and echo'able objects, but I still don't know if its right.

As for the various interfaces, 1 and 3 both suffer from lack of real introspection. You would have to create a means of exposing the values it contains. For #2 to work, you would almost have to define __call to intercept all of the values, run some sort of preg on it to figure out what is being "set". At that point, we might as well release an abstract class with that implemented so people can extend it.

All this said, I would be for 1 or 3. I like 1 because it is easily backwards compatible. It's only problem is that you loose the ability do $properties->array[3]->value->names[4].

I can see where that adds extra flexibility, and as someone said, if this is going to be PHP, why not use PHP's methods for doing it. This example brings up another point: should it be assumed that if an array is set within a Properties value that it is itself a nested Properties?


Ok - where are we on name? Marcus' Keyed is sort of growing on me. Nice, short, and simply answers "this Container is Keyed" - "this Container is Properties" makes since too, but Keyed does describe exactly what you should expect.


One quick note... I do like the idea of having a series of classes that define generic behaviors, such as URL, URI, File, Directory, SymLink, etc., etc. At that point, we're starting to move to direct competition with PEAR. Maybe that's a good thing, but that's not what I had in mind with this. I don't know the history of Java and how its evolved as I haven't done much with it until the last year, and even then its been minimal, so maybe I am going at this backwards. If that's the general concensus, maybe we do need to relook at what we're doing here and start with a code repository of basic objects. I would still like to see them done as interfaces first, then everybody can create their own implementation based off of the File, URL, and such interface. I think I said it earlier, but a possible outgrowth of this interface repository would be a code repository of what's considered "best practices" for each of the interfaces. After all, there are only so many ways you can implement File.

[illusina]

All of these are possible, but the last I'm against. Changing the behavior of an object via magic methods is ok, but changing the behavior of an internal type leads down a road that I think has a lot of boogie men waying to jump out and beat you up.

_I_ am the boogy man.

Ok - where are we on name? Marcus' Keyed is sort of growing on me. Nice, short, and simply answers "this Container is Keyed" - "this Container is Properties" makes since too, but Keyed does describe exactly what you should expect

Well, this brings up a few questions. How do we go about creating a naming scheme for Properties? Do we use nouns, do we use adverbs? I'm not up on my 9th grade grammar, but I'll try to hack it.

I personally feel that "Properties" isn't a very useful name. "Mutable" is a rather...well....loaded term to use as an interface . Mutatorable maybe . The only problem I forsee with this one is the lack of "get" in the "Mutable" interface description.

Keyed, however, does imply some interesting things. For an object to "implement" a "Keyed" interface you think to yourself that it has, somehow, provided "Keyed" methods. Seems fairly logical to me. Thoughts?

Regards,

Tyler Tompkins