> -----Original Message----- > From: Larry Garfield [mailto:larry@xxxxxxxxxxxxxxxx] > Sent: Wednesday, January 19, 2011 7:47 PM > To: php-general@xxxxxxxxxxxxx > Subject: Re: Class and interface location > > 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 > Ah... My current project is a bit similar to your intention but invoking a class depending on functionality needed and not by looking up the interface. Just about everything within the project is either interface or abstract except the 'brain' of the app. It's a MVC design intending to be 100% modular. A module may have several urls mapped to it. Any adequate third party plugins can be dropped within any module. So the problem you'll run into is this: interface IBase { function baseFunc(); } class BaseClass implements IBase { } class SubClass extends BaseClass { } class SubSubClass extends SubClass { } How would you know which class (BaseClass, SubClass, SubSubClass, or however many subs down the tree branch you may have eventually) to invoke if you're basing on just the interface ? IMHO, I think you're overcomplicating your project. I think you should design it base on the interface (ie, passing it within the parameter(s) ) but invoke the 'right' class for the functionality intended. That's why I gave the example earlier. As the project may start out with just Database. Eventually needs arise, I could implement MySQLDatabase. Then later still build another subclass and still won't break or do a major rewrite of what I started with. And I agree about loading the class(es) that probably will never used. It's very wasteful. Aso, if you haven't looked into PureMVC, I suggest you look into it. It's core program flow is pure abstract (via mainly interfaces). It uses 'observer' and notify the appropriate listener(s) class(es). I think what you're looking for is maybe its multicore with sync/async calls and/or (unix like) pipes plumbing. FYI, it does tends to implement Reflection :( So I'm rolling my own :) Regards, Tommy -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
