Proposal for Standards & Interface Repository

[Travis S]

Howdy all,

I'm a relative newcomer to SitePoint, but I've been working with PHP in some capacity for over half a decade now. The most recent discussions on patterns and the new object model in PHP 5 lend themselves greatly to libraries and classes being stitched together to make application development that much smoother. The problem has always been that once you rely on one library or classes API, you've coupled yourself to that class or a specific implementation. With pseudo-interfaces in PHP 4, and the real thing in PHP 5, there's no need for this.

My proposal is for the Open Standards & Interface Repository (will be housed at opensir.org if this takes off and people want to do it). The idea will be to create a repository of standard "libraries" such as phpCR which define an behavior of set of interfaces as well as standard interfaces for various patterns. With this, applications that then begin to rely on a Registry interface and know that whatever class they download that implements Registry will work the way they are intending it to be used.

My thought would be that all interface proposals would start out as PHP, as they progressed and became stable they would move to PECL as part of an OpenSIR extension, with the possibility that a select group of stable ones could become part of the the regular PHP distribution.

Of course, I would be willing to submit phpCR as the first "library" for review. It's already in 0.2 status as a direct port from the Java Content Repository but has areas that could probably be improved for PHP specific implementations. Also, I would be happy to put together a list of interfaces for basic patterns that could be discussed.

We would need some sort of distribution channel (a pear channel possibly?). I would need some help mirroring an effort like this. For the website, does anyone have any recommendations for software? Something more user friendly than the PEAR/PECL sites would be preferable, but a straight wiki would be hard to manage (unless someone wants to volunteer). Also, are there any designers out there that would like to lend a hand? We'd need a logo and design.

Well, before I go on too much more... Does anyone have any thoughts? I've seen several comments about people wanting a standard approach to development in PHP using a framework of some sort or another. Personally, I think we would be better off as a community to come up with standard interfaces and see what implementations come out of them. If we can agree on the API, then switching between the various implementations will be easy as they'll all be hot-swappable. Then you can really try them all out if you want before you figure out which one works for you.

Quick note on the name: I thought about doing something with PHP in the name, but decided against it. One obvious thing is the PHP's group request that projects outside of PHP not use the name. Additionally, while right now I would see the focus on PHP, I don't see anything stopping contributors at a future time from wanting to expand to include other languages as well. Common APIs across languages wouldn't be a bad idea at all and by going with OpenSIR, we keep that possibility available.

[norbert_m]

Did you see http://www.php.net/~helly/php/ext/spl/ ?

[kyberfabrikken]

While interfaces are more open-ended than implementations, they still express a concrete idea. It would therefore not be uncommon to have competing interfaces as is the case with concrete classes too. It's a good idea initially, but it has an emminent danger of becoming PEAR the sequal.

Perhaps an approach could be to rejuvenate PEAR by defining interfaces for the classes which already exists ?

but a straight wiki would be hard to manage

Some wikis have user-profiles like regular forums. This could be useful against spam.

[Travis S]

Did you see http://www.php.net/~helly/php/ext/spl/ ?

Yes, I am familiar with SPL, but I believe it's goal has been more to allow you to plug into the internals of PHP (i.e., Iterator allowing you to utilize foreach() and the various Array interfaces allowing you to overwrite array handling). It does provide many useful interfaces. I also haven't seen a means for proposing new interfaces, but I may have just overlooked it.

While interfaces are more open-ended than implementations, they still express a concrete idea. It would therefore not be uncommon to have competing interfaces as is the case with concrete classes too. It's a good idea initially, but it has an emminent danger of becoming PEAR the sequal.

Very true. I believe a lot of common demoninators can be reached at the interface level to keep them generic enough to fill the majority of common roles. JCR provides an interface generic enough to work in just about any environment, while still providing enough optional interfaces to allow for versioned nodes, locking, observation, etc.

Take the template for example. There are probably hundreds of various "template engines". They could all be broken down into one simple interface with several more added on top of it:

interface Template {
  public function assign($key, $value);
  public function display($file);
} 

This could be extended to offer the ability to have fetch(), setFile(), addPath(), etc. Then the user of the various template engines could know whether they can switch by relying on the interface they need.

Perhaps an approach could be to rejuvenate PEAR by defining interfaces for the classes which already exists ?

The thought did cross my mind. PEAR's goal is to be a code repository though. What I'm looking for is something that would provide best practice guidence for developers. I also have some personal differences with assumptions made by PEAR (the biggest being the assumption of being in the include_path). Ideally, I could see this gaining steam and PEAR becoming a repository of implementations of the various common interfaces.

That's what I'm proposing this for though, if I'm the only one that thinks that it would be better independent then maybe PEAR is the way to go.

[ghurtado]

This seems like a very good idea in principle. As kyber points out though, it might be just as hard to get the developers to agree on a particular interface as it is to get them to agree on an implementation. After all, the interface already defines a lot of things, like a coding style, a design roadmap and some other specifics that the implementation would have to follow.

Nevertheless, I would be glad to design a logo and a visual template for the website if this takes off; for now this is probably the perfect place to start to put forth ideas and consider the finer points.

I've seen several comments about people wanting a standard approach to development in PHP using a framework of some sort or another.

Absolutely. Almost any PHP developer of a certain caliber has been longing for this for quite a while now. PEAR was supposed to fill that gap, but it failed miserably, and quite honestly I don't hold much of a hope for it to change directions in the near future.

It's already in 0.2 status as a direct port from the Java Content Repository

IMHO, this has the potential of becoming a big hurdle as well. There are two mainstream movements in "Advanced PHP" nowadays. The one seems to be looking up to Java as its older brother, and thinking "that's what I want to be when I grow up". The other wants PHP to evolve in it's own right, taking advantage of what it does best and designing its own custom idioms that will advance the language as an independent entity. Neither group is 100% right, and both are probably neccesary to keep the language balanced, but I tend to caution against the dangers of mimicking Java too much without considering alternative approaches that may work much better in PHP. To provide an extreme example as an illustration (I am sure you have run accross this in the past), some PHP developers out there are creating classes for "String", "Array" and "Hashmap". I stand clear of that path, and I am sure you do too.

[jayboots]

I think this is a great idea to foster interop. A problem I see is that interface design is actually much more difficult than implementation simply because it is more abstract and has to meet needs greater than a given particular implementation might. To me that implies a well defined review process that is both critical and rigorous and involves lots of consultation.

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.

One thing about using Pear as a basis: even though its early roots have left it with a design that is not particularly beautiful -- because the Pear folks tend to stick to their guns to save compatability, it means that following their lead could help interop as there would already be at least one implementation of the interfaces. I'm actually somewhat of a purist at heart but I can't see much point in generalization unless there are multiple and concrete contact points out it the wild. In other words, if this only lead to one more implementation (say a "better" Pear) then it may not really be any more useful than Pear -- perhaps just prettier.

Lots of work, definately. Do you plan on setting up some sort of public working area to get this fleshed out or at least to help give an idea of what its scope would be?

[arborint]

While I agree with the problem (maybe) I really don't with this proposed solution. You will have the same problem that other already baked designs have, how do you get a lot of programmers to both grok your ideas and get excited about them. Your phpCR reminds me of WACT (because we have recently been discussing it). Both have lots of good ideas, good execution and a smart guy behind them with great ideas. But there is little uptake because both have solidified a group of interrelated classes and by doing so have made thousands of design decisions that shape the thing. Unfortunately there is too much done to interest other designers to get on board and take the design to the next level, and not enough done for programmers to be interested in using it for projects .

kyberfabrikken and I went through the design process on the skeleton threads and we know how difficult it is to have aligned goals, trust and good communication. Two or three people are not enough. You really need the informed input of 5-10 good programmers to make something as big a standard framework or library get to the necessary quality level. You need to start small and get a large group to have ownership in the design.

[Travis S]

Howdy all...

Well, I'm pleased that this is getting some discussion. That's what I hoped for

IMHO, this has the potential of becoming a big hurdle as well. There are two mainstream movements in "Advanced PHP" nowadays. The one seems to be looking up to Java as its older brother, and thinking "that's what I want to be when I grow up". The other wants PHP to evolve in it's own right, taking advantage of what it does best and designing its own custom idioms that will advance the language as an independent entity. Neither group is 100% right, and both are probably neccesary to keep the language balanced...

I agree completely. phpCR was a straight port because that's what I had to work with. Since there wasn't an OpenSIR to help formulate ideas and come up with the right solutions in the scope of PHP. There are areas right now that I'm sure aren't good. I've already deviated from JSR-170 in the exporting of XML. To me, it didn't make sense to use the out parameter to put the returned results in. PHP'ers are used to methods returning, so I'm returning a valid DOM. Makes more sense to me than making a user include an initialized dom as part of the exportXML() call.

These are the kinds of things I would think would be better worked out as a group, however. I might hazard an occassion streak of luck and get something right, but the odds of that happening go up exponentially with others involved.

To provide an extreme example as an illustration (I am sure you have run accross this in the past), some PHP developers out there are creating classes for "String", "Array" and "Hashmap". I stand clear of that path, and I am sure you do too.

Actually, I saw something like this proposed on PECL awhile back. The idea was to create native objects for each of the types - and I'm all for it. One of the values of PHP is diversity of ideas. Each of us have our own way of doing things and enabling all of those ideas is generally a good thing. Now I would be against doing it in PHP code just because the extra overhead wouldn't be worth it. But, if there was an internal String object that would give me a clear interface for changing type and such it would definitely give me something to consider...

The one value of having the raw values though is that the rest of the implementation for all the various conversion functions and whatnot are not automatically loaded into memory. It might be that StringObj wouldn't be worthwhile except in the rarest of cases. Possibly like the extra functionality that ADOdb provides. If you need that functionality, then its a god-send, but if I'll you're doing is querying a database and displaying the results it can be overkill. It's all a matter of the right tool for the job.

I think this is a great idea to foster interop. A problem I see is that interface design is actually much more difficult than implementation simply because it is more abstract and has to meet needs greater than a given particular implementation might. To me that implies a well defined review process that is both critical and rigorous and involves lots of consultation.

Agreed. Interface design is a much longer process. Take JSR-170 for example. It took over three years to go from initial ballot that they wanted to do it to actually releasing the final code. I'm not saying that everything will take that much time, but some of the larger projects will definitely be long haul endeavors. For something like this to work it will definitely take several people to come together and make commitments to hash out the ideas to make this happen. The coding will be a small part of what's done. Creating the entire phpCR interface as it stands now took me a few weeks working an hour or so a day - the real time had been spent by the people who created the spec for it.

Lots of work, definately. Do you plan on setting up some sort of public working area to get this fleshed out or at least to help give an idea of what its scope would be?

Yes... I can set a site up. I'm using this as a basis for determining if anyones interested, which it looks like there is some interest. We can continue to use it to hash out ideas and where to go from here. I can setup a mailing list (if people would prefer that route) and get a site online. Right now, I would be leaning toward MediaWiki as I know it, but if anyone else has any ideas shoot them my way.

While I agree with the problem (maybe) I really don't with this proposed solution. You will have the same problem that other already baked designs have, how do you get a lot of programmers to both grok your ideas and get excited about them. Your phpCR reminds me of WACT (because we have recently been discussing it).

I think you might misunderstand what phpCR is - there are only a handful of concrete classes there and they are generally inconsequential. It's composed 95% or more of interfaces. Each developer is left up to their own devices to figure out how they can best work it into their system. You might have this confused with my d51CR which is an implementation of phpCR - it's still in its infancy though and is a completely moving target as to exactly how I'm going to implement the storage behind it.


To bring this back to OpenSIR (I'm just throwing that out as a working name for the time being)... There are a few things that need to be done to move forward from here.

• Create a mission statement
• Determine the scope
• Determine a means for creating/submitting packages.
• Determine how packages are adopted

Creating a mission statement
As a rough draft...

To foster the creation and adoption of standards with the help of the international PHP community.

Or...

To foster the creation and adopts of standards identified by the international PHP community.

Thoughts, additions, deletions?

Determine the scope
I would say this is an evolving thing. At first, I think the focus could be codifying standard interfaces to patterns within PHP. My Template interface would be one example. Another is Registry. It will always need a getInstance() (or maybe instance()?) and a get() and set() method.

Eventually, I would like to see this evolve into something like JCP where full fledge specifications are being created for PHP coders.

Determine a means for creating/submitting packages.
Should individuals create the ideas and have others comment on them (a la PEAR)? Should ideas be identified/submitted and then solicit people to work on creating them?

Determine how packages are adopted
I imagine we'll need some sort of voting for this. What should the process be? Do we want voting on the final package, or should that be handled up front (i.e., yes or no we want to do this package). Is this open to everybody that wants to vote or should this be opened to members/developers only? If so, what's the requirements for membership?


Ok... This is long enough now. Your turn. Thoughts, comments?

[arborint]

I think you might misunderstand what phpCR is - there are only a handful of concrete classes there and they are generally inconsequential. It's composed 95% or more of interfaces. Each developer is left up to their own devices to figure out how they can best work it into their system. You might have this confused with my d51CR which is an implementation of phpCR - it's still in its infancy though and is a completely moving target as to exactly how I'm going to implement the storage behind it.

No, I see that it is mostly interfaces. But interfaces are the design. Given how most of the programmers here code, once the interfaces shake out there is no more than a dozen lines behind each call.

So what you have is a massive Java based design that I have only the slightest inkling of whether it is either good in PHP or the kind of code I want to use. So why should I go with those interfaces rather than the many other sets of them lying around the Internet (many battle tested)?

[paulyG]

Will it be true that through openSIR the php community will have another combined voice that the PHP maintainers will be able to see trends in PHP thinking and solutions?

Maybe less formalised than PEAR or PECL - but nevertheless "what some users are doing with PHP".

If so, it could make PHP nimbler and more reactive to the changing nature of the internet, than say Java. And that is one if its strengths, right?

[dagfinn]

Actually, I saw something like this proposed on PECL awhile back. The idea was to create native objects for each of the types - and I'm all for it.

I suppose this is slightly OT for this topic, but it seems logical. Assuming you want type hinting at all, not having it for primitive types is just artificial and half-baked.

[kyberfabrikken]

Determine the scope

Perhaps this is the important point. I think such an effort could easy strand because of the mere magnitude of it. Better to start out with a limited subject. For example, it could be interesting to see an interface formulated, which meet the featureset of all the templateengines in PEAR.

[Travis S]

Perhaps this is the important point. I think such an effort could easy strand because of the mere magnitude of it. Better to start out with a limited subject. For example, it could be interesting to see an interface formulated, which meet the featureset of all the templateengines in PEAR.

Ok... Let's go with the Template pattern. I haven't looked at any of the templates in PEAR, though I have participated in Savant and used Savant, Smarty, and my own home grown.

There are three main interfaces:

interface Template {
    public function assign($key, $value);
    public function display($file = null);
}

interface PluginTemplate extends Template {
    public function registerPlugin($name);
}

interface FilterTemplateDecorator {
    // how do we tell it about Template?  
    public function setPreFilter($callback);
    public function setPostFilter($callback);
}

// with two additional classes...

interface FileBasedTemplate extends Template {
    public function addPath($path);
    public function setFile($file);
}

interface FetchTemplateDecorator {
    // Again, ideas on making the decorator aware of the the decorated?
    public function fetch($file = null);
} 

Have I missed anything? I believe that covers all of the main uses of template engines.

The two I'm not sure on are the decorators and how to make them aware of a Template object. Should they be responsible for instantiating their own Template object, should they be given one, or should that matter?

Another question: should plugins and filters be explicit as above, or should they be part of an ObserverableTemplate? You could specify blank interfaces to signify that the ObserverableTemplate does notify for certain events (prefilter, postfilter, unknownMethod for plugin attempts).

[Travis S]

Will it be true that through openSIR the php community will have another combined voice that the PHP maintainers will be able to see trends in PHP thinking and solutions?

Maybe less formalised than PEAR or PECL - but nevertheless "what some users are doing with PHP".

If so, it could make PHP nimbler and more reactive to the changing nature of the internet, than say Java. And that is one if its strengths, right?

I agree to some extent... PHP doesn't need to become mired in standards or zealously followed best practices. However, it does need to start reaching some common ground so developers can quit re-implementing the wheel when it comes to their APIs.

No, I see that it is mostly interfaces. But interfaces are the design. Given how most of the programmers here code, once the interfaces shake out there is no more than a dozen lines behind each call.

In some cases... In phpCR there's multiple paths to strike out on once you determine which type of repository you want to setup (flat ID based or heirarchical). After that, are you going to go read-only or read-write? After that, do you implement Observation, Versioning, and Locking, or none of the above? Do you tie to one particular database storage system, XML files, or some other home-grown storage solution?

You are correct that the bird's eye design is done, but there's still a hundred different ways to implement it if you have a hundred different programmers.

[arborint]

OK, let's decide on what the interface should be, maybe:

interface Template {
    public function set($key, $value);
    public function render($file = null);
}
// or
interface Template {
    public function assoc($key, $value);
    public function output($file = null);
}
// or
interface Template {
    public function __construct($file = null);
    public function set($key, $value);
    public function display();
}
// or
interface Template {
    public function __construct($file = null);
    public function setTag($key, $value);
    public function toString($file = null);
}
// or
interface Template {
    public function loadFile($file = null);
    public function setTemplate($template_str = null);
    public function assignValue($key, $value);
    public function display();
}
// or
interface Template {
    public function __construct($file = null);
    public function set($key, $value);
    public function process($template_str = null);
}
// or
interface Template {
    public function __construct($template_path = null);
    public function setTemplateFile($file = null);
    public function setVariable($key, $value);
    public function toHTML($filename = null);
}
// or
interface Template {
    public function setFile($file = null);
    public function assoc($key, $value);
    public function render($template_str = null);
}
// or 

[Travis S]

Your post does make my point exactly - nearly every one of those does the same thing. What I've done is adopted the two largest APIs of Smarty/Savant (in their smallest form) which I believe are the ones that people will be the most familiar with.

I don't know, maybe one of PHP's strengths is its "rugged individualism". Trying to create a collection of standards might not work in its context. Although, it would be nice to be able to swap out code without having to worry about all your custom code that's tied to properitary APIs.

[arborint]

It makes your point, which I agree with, that they do nearly the same thing and we would be better off with a standard.

But you didn't go through the process of finding what the best interface is. You simply picked the one that you use and claim "that people will be the most familiar with" but I don't use that interface and I will bet that few others in this forum do either. So you have an interface that maybe a few people use, you have provided no rational that it is any good or how it is consistent with other interfaces you will implement, but you want us to change our code to your style. Why should we switch? Now multiply that times 100 interfaces.

[Selkirk]

interface Template {
    public function assign($key, $value);
} 

The WACT template class does not do the same thing:

Class Template {
    function registerDataSource(&$DataSource);
}

$data->variable = 'value';
$template->registerDataSource($data);

instead of

$template->assign('variable', 'value'); 

[arborint]

The WACT template class does not do the same thing:

Class Template {
    function registerDataSource(&$DataSource);
}

$data->variable = 'value';
$template->registerDataSource($data);

instead of

$template->assign('variable', 'value'); 

Mine based on the Skeleton DataSource supports both but calls it:

$template->set($tag, $value);
$template->import($data); 

But Selkirk's is a more expressive name. Yeah, let's use that one. Ready to change all your code to this style Travis?

[Overunner]

But Selkirk's is a more expressive name.

I think the name "registerDataSource" is too long. How about setMultiple/setVars/setArray?

Should the template be able to include sub-templates btw?

[Travis S]

The WACT template class does not do the same thing:

Class Template {
    function registerDataSource(&$DataSource);
}

$data->variable = 'value';
$template->registerDataSource($data);

instead of

$template->assign('variable', 'value'); 

At which point we would also need to define what a datasource can be.

But Selkirk's is a more expressive name. Yeah, let's use that one. Ready to change all your code to this style Travis?

If that were to become an agreed upon standard, yes. Of course, I would write an adapter to make sure I didn't break any existing code, but I would start a migration.

My first Template code missed on key thing - that was just an idea. As we've demonstrated here, there are many different ways to do the same thing.

Maybe there are just too many ways to do things in PHP to come up with a set of standard interfaces...?

[sweatje]

Maybe there are just too many ways to do things in PHP to come up with a set of standard interfaces...?

Just as many as in Java. Why can they agree on standards where we can't?

[Travis S]

Should the template be able to include sub-templates btw?

I would say that a Template should be able register anything. Something along these lines would not be an uncommon bit of code:

$header = new EchoableTemplate();
$header->setFile('header.html.php');
$page = new Template();
$page->set/assign/etc('header', $header);
$page->display('page.html.php');

// inside page.html.php
<?php echo $header; ?>

[Sgarissta]

Just as many as in Java. Why can they agree on standards where we can't?

Because theirs are pushed down from above for starters. The SPL is an attempt, in my opinion, for "the powers that be" in the PHP world to attempt to push some semblence of standards upon everyone. The problem being is they lost most of their credibility due to the PEAR debacle. I also think a big reason it won't work is that the vast majority of PHP programmers, didn't start as programmers, and aren't really interested in standards, just "making it work".

But most importantly, unlike Java PHP doesn't have a real central community of any sort. You've got the internals folks, you've got sitepoint, you've got PHPBuilder, and dozens of other smaller community sites. There's just no reasonable way at this point, without a mandate from zend/internals folks, to get standards introduced, agreed upon, and more importantly implemented.

[Travis S]

Just as many as in Java. Why can they agree on standards where we can't?

Possibly because of PHP's lower barrier to entry...?


Based on what I'm seeing here, I think there's a lot of FUD about interfaces. Again, just because you have to call set(), or assign(), or registerData(), it doesn't mean you have to adhere to anything more than that API. It's no different than saying you implement a particular pattern - the only difference is with an interface you can prove you've implemented the pattern in an expected manner and others can rely on a particular API to be made available and based on how much they trust your coding style a particular result