On Wed, 2011-01-19 at 21:46 -0600, Larry Garfield wrote:
> 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
>
Maybe it's the noob in me, or the lack of smrts... but couldn't you just
add a var in the class, and set it like:
$GLOBALS['classes_that_do_things']['name'] = 'class_name';
And for those that do 'things', and then do the foreach on that?
foreach($GLOBALS['classes_that_do_things']['name'] as $class_name) {...}
not sure if that would work or not, it was just something that was in
the cobwebs of my brain this morning.
Steve
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
