> -----Original Message-----
> From: Larry Garfield [mailto:la...@garfieldtech.com]
> Sent: Wednesday, January 19, 2011 7:47 PM
> To: php-general@lists.php.net
> Subject: Re: [PHP] 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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 :)


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

Reply via email to