Proposal for Standards & Interface Repository

[dagfinn]

All your DB Connector cares about is that $config->get('DBName'), etc. exist. It's all about the interface.

Yeah. But for interoperability, get() is not what matters, DBName is. So to ensure that it's pluggable, having an interface with getDBName() in it seems more reasonable.

[ahundiak]

SPL is the standard php library....which houses the exception class, but can be turned off in the .ini file or when compiled.

Can you provide a link to this one? Accoding to the PHP site, SPL provides additional Exceptions as well as various interfaces and classes. But the Exception class itself as well as the try/catch/throw mechanism is part of the core. Nor could I find any documentation on an ini setting for disabling exception processing.

There have been some bug reports concerning throwing exceptions inside of __get. The ones from several years ago have been marked as fixed. One from June 2004 is inactive.

[Selkirk]

So many excellent points here. I wish I had time to reply to more.

I think of Keyed as the object form of a PHP associative array.

Isn't there an interface in SPL for that already?

I think of this as a defining the properties facet of a PHP component specification.

We really should not underestimate the powerful benefits of this. I have been meaning to itemize this list that lastcraft rolls out naturally. If your Request, Config, DB Row, Template, and Response all use the same container interface then many things are simplified and interesting possibilities occur.

Such is the power of components. All of those things are components.

Earlier you asked "are we trying to ... create a standard interface for simple keyed containers?"

Simple keyed containers are the properties facet of a component API.

The first post of the thread brought up the possibility of modifying PHP itself. The name of the thread is "standards & interface." Properties can be a standard just as well as it can be an interface.

I see three main posssibilities:

1. Think "inside the PHP box."
   Define an interface with set()/get(). I have NO problem with this. WACT has exactly this now. Seriously, I have no problem with this. WACT has had DataSource components in it since day one. I've been working with a set()/get() interface for years. And yet...
2. Think "I am one with the box I'm in."
   Use a standard instead of an interface. Access properties with -> and deal with the flaws involved with implementing accessor methods using __get and __set. Longer term, I'm looking here. Conceptually, I think -> is the place to be. It feels more PHP like. Its more concise, easier to read and understand. Yet, there are so many rough edges.
3. Think "Am I in the right box?"
   My current thinking is that the best long term solution is to attempt to get native accessor methods in PHP. I am seriously looking at implementing this myself and trying to get it in PHP 6, then taking WACT from directly from 4 to 6.

I think __get and __set on an interface is a dead idea.

Anyway, I'm glad to see some of the PHP compatibility issues being raised:
What if you set a property that isn't there? (create one or error?)
What if you get a property that isn't there? (return NULL or error?)
What if you hasProperty a property that exists and is NULL? (return TRUE or FALSE?)

[arborint]

Isn't there an interface in SPL for that already?

I don't think ArrayObject is in the spirit I was thinking of. It exists to support ArrayIterator from what I can see.

I think of this as a defining the properties facet of a PHP component specification.

Such is the power of components. All of those things are components.

Earlier you asked "are we trying to ... create a standard interface for simple keyed containers?"

Simple keyed containers are the properties facet of a component API.

I think a minimum standard for a component such as we are discussing would be a step toward interop between the absurd number of classes in PHP. And interop means apples and apples comparison which will act to cull all the low quality variations (i.e. those with out unit tests)

The first post of the thread brought up the possibility of modifying PHP itself. The name of the thread is "standards & interface." Properties can be a standard just as well as it can be an interface.

Given the problems around PHP5 I think it may be time to be more involved in PHP internals because something is not right.

I see three main posssibilities:

1. Think "inside the PHP box."
   Define an interface with set()/get(). I have NO problem with this. WACT has exactly this now. Seriously, I have no problem with this. WACT has had DataSource components in it since day one. I've been working with a set()/get() interface for years. And yet...
2. Think "I am one with the box I'm in."
   Use a standard instead of an interface. Access properties with -> and deal with the flaws involved with implementing accessor methods using __get and __set. Longer term, I'm looking here. Conceptually, I think -> is the place to be. It feels more PHP like. Its more concise, easier to read and understand. Yet, there are so many rough edges.
3. Think "Am I in the right box?"
   My current thinking is that the best long term solution is to attempt to get native accessor methods in PHP. I am seriously looking at implementing this myself and trying to get it in PHP 6, then taking WACT from directly from 4 to 6.

I think you clearly state the options or steps to nirvana. But my main point in all of this is that PHP is stuck at number 0. If we can get a good part of the PHP community to start using something like minimal version of the WACT DataSpace (see Skeleton DataSpace) then we can get PHP on the road from 1 -> 2 -> 3. But I truely believe we need to get a critical mass using get()/set() containers to move forward.

I think __get and __set on an interface is a dead idea.

And good riddance.

Anyway, I'm glad to see some of the PHP compatibility issues being raised:
What if you set a property that isn't there? (create one or error?)
What if you get a property that isn't there? (return NULL or error?)
What if you hasProperty a property that exists and is NULL? (return TRUE or FALSE?)

I really don't have an opinion about exceptions because I think the jury is still out on how to best use them in PHP. My point all along has been that people who use PHP have an expectation (good or bad) that things will work a certain (mushy) way. That's why I proposed, whether they throw exceptions or not, that get/set have the same feel as associative arrays, which means using NULL. Because the reality is that the current container standard in PHP is the associative array. It is used for all the things that we want people to use containers for. So we should not annoy unnecessarily.

[kyberfabrikken]

My point all along has been that people who use PHP have an expectation (good or bad) that things will work a certain (mushy) way. That's why I proposed (...) that get/set have the same feel as associative arrays, which means using NULL. Because the reality is that the current container standard in PHP is the associative array. It is used for all the things that we want people to use containers for. So we should not annoy unnecessarily.

Very true.

[mx2k]

http://www.php.net/~helly/php/ext/spl/spl_8php.html

http://www.php.net/~helly/php/ext/spl/

but it looks like your right and they have the exception class in the core engine now, according to the spl documentation.

i know i read somewhere that the spl could be turned off since its an extention, but i can't remember exactly where.

[jayboots]

I really don't have an opinion about exceptions because I think the jury is still out on how to best use them in PHP. My point all along has been that people who use PHP have an expectation (good or bad) that things will work a certain (mushy) way. That's why I proposed, whether they throw exceptions or not, that get/set have the same feel as associative arrays, which means using NULL. Because the reality is that the current container standard in PHP is the associative array. It is used for all the things that we want people to use containers for. So we should not annoy unnecessarily.

But get()/set() are annoying and very unlike array access. Have you considered using straight arrays? ) that's tongue-in-cheek because I've lost heart until we get to general containers)

[arborint]

But get()/set() are annoying

I am starting to think being annoying to you might become one of our requirements for these interfaces.

and very unlike array access. Have you considered using straight arrays? ) that's tongue-in-cheek because I've lost heart until we get to general containers)

I think they are very alike for two reasons:

1. You use a scalar key to access the data.

2. As I said above, the current container standard for PHP is the associative array. So if we can move programmers to a simple get()/set() container we have them thinking about objects as containers. That is the first goal.

[jayboots]

I am starting to think being annoying to you might become one of our requirements for these interfaces.

If that is your definition of success, then job well done! lol

I think they are very alike for two reasons:
1. You use a scalar key to access the data.

2. As I said above, the current container standard for PHP is the associative array. So if we can move programmers to a simple get()/set() container we have them thinking about objects as containers. That is the first goal.

I oppose the idea that this is making things simpler particularly since it 1) changes the way people already do things, 2) doesn't add anything to what is already available. For example, this very interface already exists in SPL: http://www.php.net/~helly/php/ext/spl/interfaceArrayAccess.html -- oh wait, it includes an unset so surely it is not acceptable here. *shrug*

[arborint]

I oppose the idea that this is making things simpler

I can't imagine that you actually oppose making things simpler, nor does using a container make things simpler.

particularly since it 1) changes the way people already do things,

Not really, currently if you have a scaler key and they want to save data somewhere using that key, then associative arrays are your container

2) doesn't add anything to what is already available.

I certainly goes well beyond associative arrays (when they are used as containers). And, yes there are many similar things out there, but no minimum standard.

For example, this very interface already exists in SPL: http://www.php.net/~helly/php/ext/spl/interfaceArrayAccess.html -- oh wait, it includes an unset so surely it is not acceptable here. *shrug*

I think this is a prime example of what is wrong with SPL. There is general agreement that a container is something that PHP needs, yet SPL goes off and reimplements array. The PHP array has to be about the most flexible well supported thing if its kind in any programming language. Giving it native object support like Selkirk has suggested in the logical next step. But SPL seems to be aiming at Java 5 years ago as its target.

[jayboots]

I can't imagine that you actually oppose making things simpler, nor does using a container make things simpler.

Of course I don't oppose making things simpler, if they are indeed making things simpler. I'm sure we all agree on this point; however, we seem to disagree on the criteria for something being simpler or not.

Not really, currently if you have a scaler key and they want to save data somewhere using that key, then associative arrays are your container

Hmm. Be sure that I most certainly understand these primitive principles. My point is that get/set introduces arbitrary new syntax and moreso goes in a direction that is really based on Java principles (explicit method access). The reason some folks have suggested [] access and others (like myself) -> access is just because in PHP people already use [] for arrays and -> is natural in PHP since it exposes public members, unlike some certain other languages. Ignoring this ignores the very things that makes PHP so simple, as far as I am concerned.

I certainly goes well beyond associative arrays (when they are used as containers). And, yes there are many similar things out there, but no minimum standard.

I don't understand your meaning here.

I think this is a prime example of what is wrong with SPL. There is general agreement that a container is something that PHP needs, yet SPL goes off and reimplements array. The PHP array has to be about the most flexible well supported thing if its kind in any programming language. Giving it native object support like Selkirk has suggested in the logical next step. But SPL seems to be aiming at Java 5 years ago as its target.

If this is what you think, then perhaps you should reconsider what is being done with this current interface because from my POV that is EXACTLY what it is doing.

At any rate, it has never been my intention to be an obstacle to this process. From the outset I stated my goals (exploiting PHP's dynamic features) and asked if it was appropriate for me to post into the thread. Perhaps the initial reaction that I received was not really in-line with the goals of this thread after all. That's not a problem for me and if you don't think I should participate further, just say so. After all, this much head-butting isn't that much fun, yes?

best regards.

[arborint]

Hmm. Be sure that I most certainly understand these primitive principles. My point is that get/set introduces arbitrary new syntax and moreso goes in a direction that is really based on Java principles (explicit method access). The reason some folks have suggested [] access and others (like myself) -> access is just because in PHP people already use [] for arrays and -> is natural in PHP since it exposes public members, unlike some certain other languages. Ignoring this ignores the very things that makes PHP so simple, as far as I am concerned.

I am not opposing -> access because I think it is inferior, I hope it is the long term solution. But it is PHP5 only and problematic even in PHP5.

The difference between ->/[] access and get()/set() is that the latter is the simplest, minimum way to allow a separation between interface and implementation in both PHP4 and PHP5 right now.

What I am supporting is coming up with a workable keyed access container that works now. The WACT DataSpace is a prime example of the utility of this. Selkirk is thinking ahead because DataSpace is a two year old idea for him. But it is new to much of the PHP world. If we can get people up to that point (and get a little interop between frameworks like Mojavi and WACT) then we can get a critical mass of programmers on the path that people like Selkirk and illusina are currently on.

If this is what you think, then perhaps you should reconsider what is being done with this current interface because from my POV that is EXACTLY what it is doing.

I think it depends on you thoughts about the difference between containers and arrays. Arrays are already well supported in PHP. Now if you want to add things like $array->count, I would be for that.

At any rate, it has never been my intention to be an obstacle to this process. From the outset I stated my goals (exploiting PHP's dynamic features) and asked if it was appropriate for me to post into the thread. Perhaps the initial reaction that I received was not really in-line with the goals of this thread after all. That's not a problem for me and if you don't think I should participate further, just say so. After all, this much head-butting isn't that much fun, yes?

I don't think anyone is an obstacle who is trying to understand the issues and working towards solutions. Going back to your first post, you said:

Another problem is that all the interfaces in the world won't help anyone unless they are easy to implement in a particular system. As there is no set standard for a framework design in PHP, perhaps this is best place to start. Good luck though trying to get a consensus on that one Not that you need 100% buy-in, of course. I just think it would be a good starting point because it would help give a better picture of the types of things that you might want to see standardized.

My feeling is that get()/set() best meets the "are easy to implement in a particular system" requirement for the current state of PHP. If PHP5 had been a wild success and had 80% adoption I would have a different opinion. But our reality is PHP4, little/no interop between frameworks, and people still asking "Should I use objects rather than procedural..." questions.

[arborint]

In PHP5, classes and interfaces share the same namespace (like it or not). So, should there be a standard like C#s prepending "I" to everything (e.g. IKeyed). I notice that the PHP docs and SPL give a nod toward name ending with "*able" (e.g. Keyable) but are hardly consistent.

I am sure there are opinions, but is there any consensus on naming interfaces in PHP?

[jayboots]

I already prefix with "I" and also "A" for abstract, so I'm all for that.

[kyberfabrikken]

I like I

[sweatje]

I like I

Shouldn't that be ILike

[jayboots]

I should add that I still think it is not a good idea to take popular names on their own but rather to prefix with the project name, eg: ISIRKeyed or ISIR_Keyed or maybe just SIR_Keyed...or what-have-you. Amongst many factors, it should make google searches easier Also, since ISIR sounds like

@sweatje -- lol

[lastcraft]

Hi.

Please don't prefix. It just adds clutter, and there is no reason for class names to have the same names as interfaces. They are fundamentally different things. One's a role, the other is a capability. Prefixing is Hungarian notation without a point and will store up problems for when PHP gets namespaces.

If you are going to prefix (again, please don't) then go InteropKeyed. Acronyms just create confusion with captilaisation, and abreviations just cause confusion full stop.

yours, Marcus

[Dr Livingston]

Nothing wrong with Prefixing interfaces and classes. There is absolutely no clutter at all just because you prefix the letter I to an interface, or prefix the term Abstract to an abstraction.

Next thing you'll be saying, is that it's bad practice as well, to prefix your filenames, such as,

ifilter.class.php
...
filters/login.class.php
filters/authentication.class.php
...

Developers have for years, been prefixing their interfaces and classes, and no doubt it's going to continue for some time yet. It's down to personal preference, and has little to do with namespace clutter.

Do you have anything concrete on how using I and Abstract could be a problem Marcus? I just don't see what the problem is. For whatever amount of confusion that could arise, then one relatively easy solution to that is clear documentation.

Some businesses require that you have prefixes, how do you convince them to drop them? How do you convince them that their organisational standards are confusing?

[arborint]

Well, as ever I am sorry when I ask about naming. I also think that the name matters less than whether people acutally use the interface.

One thing that came up in the course of my back and forth with jayboots is that there are two different design spheres in PHP at the moment.

1. There is the PHP4/PHP5 sphere where the focus is having things work for the current versions of PHP but with an upward design path,

2. The PHP5/PHP6 sphere where PHP4 (and its problems) are abandoned, so there are more advanced OO possiblities.

Having people in those different spheres attempt to come up with a common design is a futile, interseting at times, but a waste of time. So I would propose that in the future we first determine in which design sphere we are working.

So, after all of that, is there any real value or interest in the interface Keyed in the PHP4/PHP5 sphere:

interface Keyed {
function get($key);
function set($key, $value);
function has($key); 

[McGruff]

Please don't prefix.

I'll second that. "IHurtToRead" is the devil's work, I tell ye

[33degrees]

So, after all of that, is there any real value or interest in the interface Keyed in the PHP4/PHP5 sphere:

interface Keyed {
function get($key);
function set($key, $value);
function has($key); 

Unless I'm mistaken, the whole reason for defining this interface was to promote interoperability between the components that implement it, and that's as much of a concern under php4 as it is under php5. The fact the php4 doesn't actually have an 'implements' keyword is besides the point.

[dagfinn]

Please don't prefix.

For some opinions on this issue, read
DontDistinguishBetweenClassesAndInterfaces.

[McGruff]

The fact the php4 doesn't actually have an 'implements' keyword is besides the point.

Agreed. I do use interfaces a lot in v4 although it's really just documentation:

        class Foo // implements Bar
        {
            // etc 

Whenever I find an interface, a skeleton class goes in an "interfaces" folder. Again it's really just documentation although they're also handy for creating mocks.

If hints are required in the code you come up with fair enough. If not, it might be nice to be able to use it in v4. Freelancers working on smaller scale web sites will have to support v4 for some time to come.

[arborint]

Unless I'm mistaken, the whole reason for defining this interface was to promote interoperability between the components that implement it, and that's as much of a concern under php4 as it is under php5. The fact the php4 doesn't actually have an 'implements' keyword is besides the point.

I agree completely, my hope is that PHP4 code would adhere to this standard as well as PHP5 code.

I think the goal here is to get minimal, useful standards that we can _agree_ on. The reason I think it is important is that I see people like Selkirk and illusina and wei travelling down interesting path(s) with frameworks and the rest of the PHP world stuck in the doldrums. A little interop between frameworks and some standards to use for all of these common classes like Request/Response, Template, DB Record Set, Config, etc. etc. and it might put a little wind in PHP's sails.

I should note that I have (right or wrong) promoted including PHP4 compatiblity into the mix because I think it is important to get people to start using basic containers. By the time that (hopefully) happens, maybe we will have PHP5/PHP5 magic move us another step forward with things like accessor based containers, DI (using interface/container introspection info), etc. etc.