Re: New Obj-C root class and forwarding
Re: New Obj-C root class and forwarding
- Subject: Re: New Obj-C root class and forwarding
- From: Christopher Sean Morrison <email@hidden>
- Date: Tue, 18 Mar 2003 16:32:43 -0500
>
> [...]
>
> My goal was to create a new root class (i.e. that does not inherit from
>
> NSObject (or Object for that matter)) that conforms loosely to some
>
> interface that defines minimal abstract functionality and data. The
>
> problem I get is that I get a run-time error regarding message
>
> forwarding:
>
>
Conforms loosely???
Perhaps a poor choice of words? Maybe replacing "conforms loosely" with
"utilizes some data members and abstract functionality" will sit better.
My base class (Circle in this case) will of course have all of the
facilities of it's inherited interface available, just not being used by
the base class itself. This is semantics, though, and an aside to my
actual issues.
>
Your code is not what you're describing. In Objective C the closest
>
thing to a Java interface is called a protocol, and has no instance
>
variable. What you call an interface above, Shape, is actually a class
>
declaration, in need of a definition (@implementation). Circle is not a
>
root class but the declaration of a subclass of Shape.
I'm aware of protocols, and specifically do not want that, nor am I
considering Java's symantics or behavior. What I was calling an interface
is based on the simple fact that I'm declaring an Objective-C @interface.
The fact that this ends up being an instantiable object is good to know
(and I did know), though I would have expected this to not have an impact
on whether Circle is still considered a root class.
What is the reasoning for allowing interfaces to be instantiable? Is
there a method for creating a virual/non-instantiable abstract base class?
Protocol's don't cut it because the only define behavior on data, not the
data itself.
>
This is also wrong: your "instantiator", a class method returning self
>
will return the Circle class object, not an instance of Circle
>
(although this has nothing to do with your problem).
That's good to know! So, then, should this class methad actually allocate
memory for a Circle and return it at this point? That makes sense to me
now that I think about it, but raises other questions about limits of
class object behavior and limitations.
>
This has already been adressed in other messages: implement the
>
NSObject protocol. In addition, you should probably give another look
>
to the available Objective C documentation. It's in
>
/Developer/Documentation/Cocoa/ObjectiveC .
This really sounds like my questions have been either fairly largely
misinterpreted or misunderstood. Implementing NSObject protocol may be a
requirement imposed by linking with -lobjc, but is not a
language-intrinsic limitation. I'm trying to determine the limits and
behavior of the language, not reimplement NSObject. I have no need or
want to implement the retainment and self-introspection mechanisms
provided by the NSObject protocol. If I do have to implement the NSObject
protocol, _why_??
If I work with Objective-C implementations on other platforms, this all
goes away and works like I expect (save some big bugs in the code that I
posted (like the class object I'm returning in Shape)).. So what are the
differences I'm running up against and why? Regardless, thanks to all for
their advice and suggestions. I'll read the Cocoa Objective-C
documentation again, though it quickly digresses into Cocoa and NSObject
behavior.
Cheers!
Sean Morrison
U.S. Army Research Laboratory
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.