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();
$c->doStuff($o);
}
}
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
