> -----Original Message----- > From: Steve Staples [mailto:sstap...@mnsi.net] > Sent: Thursday, January 20, 2011 5:16 AM > To: Larry Garfield > Cc: php-general@lists.php.net > Subject: Re: [PHP] Class and interface location > > 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 >
@Steve, That would mean that class have to be either loaded/invoked. Larry doesn't want that. He wants a way to include the right class and instantiate it. " 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" You wouldn't see the performance difference when your project is very small. But when it reaches several hundreds files+, including all of them will be a performance killer. @Larry, After a good night's rest, I just realize that what you're asking is similar to another thread discusion. This sounds like a 'cache' management problem doesn't it? Consider that part of the page (DB model objects, PHP generated html, etc,) is cached, what's not cached means that the cache management would have to include those class(es) and instantiate it/them. So in the no cache environment, a file may include about 50 files (interfaces, abstracts, superclasses) while the cache environment would only need to include about 5-10 or so. Regards, Tommy -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
