On Aug 14, 2009, at 7:15 PM, Adrian Crum wrote:
--- On Fri, 8/14/09, David E Jones <d...@me.com> wrote:
Simpler yes (for the framework implementation at least, not
for the code that uses it), cleaner... I don't know.
Please keep in mind that the branch I've been working on is
not complete, and eventually there will be no dependencies
from the context component code to the other components...
ie that's the whole goal, it's just not done yet.
Then you must have access to some voodoo I'm not aware of. If an
interface references a class in the entity component, then how will
there be no dependency on it?
That's where the choice I was talking about a long time ago comes
in... there may be other options but these are the main two ones I've
been working with:
1. create an interface for the class referenced by the other
interface, making it part of the high level interfaces
2. remove the method from the interface, leaving it on the
implementing class meaning you have to use a type cast to the
implementing class in order to use it (and it won't work for other
implementations of the interface)
This is not always an easy decision... so I imagine we'll have various
discussions about specific methods. For my part I'm taking a first
pass and trying to keep things at a high level and somewhat
simplified, and we may decide to expand the interfaces in the future
by adding the methods and creating additional interfaces. The
distinction I'm trying to go for is those methods/classes that are
likely to be used in applications that those that are lower-level.
-David
