On Wednesday, January 19, 2011 8:56:50 pm Tommy Pham wrote:

> > And actually, thinking about it, I wonder if requiring the explicit
> declaration
> > is a good thing anyway because then it's immediately obvious and
> > greppable what the class does. :-)
> > 
> > --Larry Garfield
> You mean requiring explicit declaration of
> > class Bob implements Foo {
> > 
> > }
> It's so you can guarantee your app from future breakage because the
> interface guarantees minimum functionality and still maintain great
> flexibility such that:

Well, let me offer a more precise example of what I want to do:

interface Stuff {
  function doStuff($a);

interface Things extends Stuff {
  function doThings($a);

class Bob implements Stuff {...}

class Alice implements Stuff {...}

class George {}

class Matt implements Things {...}

function make_stuff_happen($o) {
  foreach (class_that_implements_stuff() as $class) {
    $c = new $class();

The above code should iterate over Bob, Alice, and Matt, but not George.  The 
trick is how to implement class_that_implements_stuff() (or rather, 
class_that_implements_something('Stuff')) in a sane and performant fashion 
that supports auto-loading.

If all of the above is together in a single file, it's dead simple with 
get_declared_classes() and class_implements().  However, in practice there 
could be some 200 interfaces -- with each installation having a different set 
of them -- and as many as 500 classes implementing some combination of those 
interfaces, possibly multiple on the same class -- also with each installation 
having a different set of them.  I do not want to be forced to include all of 
those classes and interfaces on every page load when in practice only perhaps 
two dozen will be needed on a particular request.  That makes 
class_that_implements_stuff() considerably tricker.

That let naturally to having a cached index (in a database, in a file with a 
big lookup array, whatever) that pre-computed which class implements what 
interface and what file it lives in, so that we can easily lookup what classes 
we need and then let the autoloader find them.  (Previous benchmarks have 
shown that an index-based autoloader is actually pretty darned fast.)  That 
just makes building that index the challenge, hence this email thread.

Thinking it through, however, I am now wondering if, in practice, indirect 
implementation (class Matt above) will even be that common.  It may not be 
common enough to be an issue in practice, so requiring Matt to be declared as:

class Matt implements Stuff, Things {...}

isn't really that big of a deal and makes the indexer considerably simpler.  
We actually have one already that indexes class locations; it just doesn't 
track interfaces.  

I also, on further review, don't think that class-based inheritance will ever 
be an issue.  The following:

class Mary extends Alice {...}

Would not make much sense at all because then both Mary and Alice would run, 
so Alice's code would run twice.  So I may be over-complicating the situation.

(For those following along at home, yes, this is essentially observer pattern.  
However, it's on a very large scale and the thing being observed may not 
always be an object, so the usual active registration process of instantiating 
both objects and telling them about each other on the off chance that they 
*may* be needed is excessively wasteful.)

Does that make it clearer what I'm trying to do?

--Larry Garfield

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to