Re: Vertical inheritance with a non-abstract superclass
Re: Vertical inheritance with a non-abstract superclass
- Subject: Re: Vertical inheritance with a non-abstract superclass
- From: David Elliott <email@hidden>
- Date: Mon, 10 Mar 2008 18:03:33 -0400
On Mar 10, 2008, at 4:51 PM, David Avendasora wrote:
On Mar 10, 2008, at 3:43 PM, David Elliott wrote:
Woah. Hold up there. If you fetch one of the subclasses you will
see one query. It will join the subclass table with the base
table. That's it.
It's only when you fetch the base abstract class that EOF must
necessarily use one query for each subclass. That is, after all,
the entire point of vertical inheritance.
Huh, I swear it would always grab everything for each subclass which
confused me at the time because, as you said, that is the entire
point of VI, but when I watched the SQL, I was sure that it went and
queried everything. I can't check now as I left VI behind a while
ago. I'll take your word for it though.
You know it's been a while but I absolutely do not recall this being
the case. I could be wrong though. Or it may be DB specific.
But again, it all boils down to one simple fact: Do not use
inheritance for YOUR benefit. Find a different way to get
polymorphic behavior. Recognize that KVC effectively makes every
property its own interface (because valueForKey("foo") or
takeValueForKey(bar, "foo") works on any object with that
property. This is ultimately a watered-down version of an
Objective-C truism. Namely that every method selector effectively
implicitly defines its own interface with exactly one method.
You know, it's simple things like these that when I read them I
wonder why I didn't think of them.
Glad you got it though. A lot of people just scratch their heads at
that statement. The same is true really of any language that does
dynamic dispatch via a selector-like mechanism. For example, consider
Python (note: my syntax may be imperfect):
class Foo:
def doSomething(self,blah):
pass
class Bar:
def doSomething(self,blah):
pass
def makeObjectDoSomething(obj, blah):
obj.doSomething(blah)
Notice how obj can either be of class Foo or class Bar and
makeObjectDoSomething can still work even though you have no
officially declared interface for a doSomething method.
The only problem with this method is that for it to really be useful
you must not be able to overload a method with the same name and same
number of arguments accepting different statically-determined argument
types. In Python it works because arguments lack types and therefore
it is impossible to overload doSomething taking one argument (or two
if you consider the semi-implicit instance argument). In Objective-C
it works because although there are types they aren't really checked
and you typically encode them into the method name (e.g.
doSomethingWithBlah:).
In fact, that's the reason why you include the type name in the
Objective-C selector name. You cannot have doSomething: taking two
different types of arguments because to the runtime they are the same
method. That still holds true even for unrelated classes,
particularly if you intend to message them via the base "id" receiver
type.
The workaround in Java at compile time is of course to declare the one-
method interface. Which isn't so bad really aside from making your
source tree larger merely to satiate the compiler. The workaround at
runtime is to water the concept down to KVC or to directly use the
reflection APIs.
-Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden