 | | From: | Tilo_Prütz | | Subject: | gcc+GNU-runtime: classes responding to instance methods | | Date: | Sat, 20 Nov 2004 09:40:22 +0100 |
|
|
 | Hi,
I experienced that - in the GNU runtime - classes are responding
to their instance methods. The API call class_get_class_method returns a
non null method and when sending an instance message to the class the
instance method is called.
I used gcc 3.4.2. Does anybody know if this is a bug?
I can't imagine that this is intended.
greetz
>tilo
|
|
| | From: | Sherm Pendley | | Subject: | Re: gcc+GNU-runtime: classes responding to instance methods | | Date: | Sat, 20 Nov 2004 05:28:18 -0500 |
|
|
| Tilo Prütz wrote:
> I experienced that - in the GNU runtime - classes are responding
> to their instance methods.
If you're referring to instance methods defined in a root class, that is
the correct behavior. Class objects respond to such methods by design.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
|
|
| | From: | Tilo_Prütz | | Subject: | Re: gcc+GNU-runtime: classes responding to instance methods | | Date: | Sat, 20 Nov 2004 12:54:48 +0100 |
|
|
| Sherm Pendley wrote:
>
> If you're referring to instance methods defined in a root class, that is
> the correct behavior. Class objects respond to such methods by design.
>
> sherm--
Oh ... that clarifies something :).
Does a specification or so existing where the intention for this design is
explained? I do not understand the sence of such behaviour. This could
even lead to segfaults because the ivars contains garbage. As I see it it
just forces the designer of a root class to be extremly careful (what
(s)he should be in any case) and to put in no ivar except the 'isa' class
pointer.
Thanks
>tilo
--
Composed with the aid of http://dict.leo.org ;).
|
|
| | From: | Michael Ash | | Subject: | Re: gcc+GNU-runtime: classes responding to instance methods | | Date: | Sat, 20 Nov 2004 06:24:28 -0600 |
|
|
| Tilo Pr?tz wrote:
> Sherm Pendley wrote:
>
>> If you're referring to instance methods defined in a root class, that is
>> the correct behavior. Class objects respond to such methods by design.
>>
>> sherm--
>
> Oh ... that clarifies something :).
> Does a specification or so existing where the intention for this design is
> explained? I do not understand the sence of such behaviour. This could
> even lead to segfaults because the ivars contains garbage. As I see it it
> just forces the designer of a root class to be extremly careful (what
> (s)he should be in any case) and to put in no ivar except the 'isa' class
> pointer.
In ObjC, classes are also objects, just like everything else. This means
that a class has to have a class as well. This is commonly referred to as
the "meta class". If you take an instance of class Foo, its isa is the
class Foo. If you take *its* isa, you get the Foo meta class. For reasons
which I've forgotten at the moment, all meta classes have a superclass of
the root object. This means that all class objects are treated as
*instances* of the root object.
It does look like this would break any root classes which have ivars other
than isa, but why are you doing that anyway?
|
|
| | From: | Tilo_Prütz | | Subject: | Re: gcc+GNU-runtime: classes responding to instance methods | | Date: | Sat, 20 Nov 2004 13:44:33 +0100 |
|
|
| Michael Ash wrote:
> In ObjC, classes are also objects, just like everything else. This means
> that a class has to have a class as well. This is commonly referred to as
> the "meta class". If you take an instance of class Foo, its isa is the
> class Foo. If you take *its* isa, you get the Foo meta class.
I know...
> For reasons
> which I've forgotten at the moment, all meta classes have a superclass of
> the root object. This means that all class objects are treated as
> *instances* of the root object.
I don't see any sense in that.
> It does look like this would break any root classes which have ivars other
> than isa, but why are you doing that anyway?
Because. :) If I must not, the language has to avoid it. It does not,
therefore I'm thinking I am allowed to create my own root class and design
it as I want it to be designed.
If it is so bad to build an own root class, the language should provide
one which must be used. And the language should forbid the creation of
another root class.
greetz
>tilo
P.S.: I build up my own little framework just for fun and learning. I
think I will never program any releasable app using it, but who cares? It
is useful nevertheless, since it has produced an unit test framework which
is more powerful than other objective-c unit test frameworks I know about.
Maybe I think so because it exactly provides what I (and my employer where
I integrated it into the libFoundation based framework) need.
|
|
| | From: | Michael Ash | | Subject: | Re: gcc+GNU-runtime: classes responding to instance methods | | Date: | Sat, 20 Nov 2004 07:20:21 -0600 |
|
|
| Tilo Pr?tz wrote:
> Michael Ash wrote:
>
>> For reasons
>> which I've forgotten at the moment, all meta classes have a superclass of
>> the root object. This means that all class objects are treated as
>> *instances* of the root object.
>
> I don't see any sense in that.
One good reason is to keep duplication of code at a minimum. Instance
methods in the root class can be looked at as methods that all objects
should respond to. Things like isKindOfClass: and respondsToSelector: live
there. It would be wasteful to have to have two copies of every "base"
method like that just so that classes could also respond to them. It would
also make it so that for each root class, you actually have *two* root
classes, one root class for objects and another root class for instances.
>> It does look like this would break any root classes which have ivars other
>> than isa, but why are you doing that anyway?
>
> Because. :) If I must not, the language has to avoid it. It does not,
> therefore I'm thinking I am allowed to create my own root class and design
> it as I want it to be designed.
>
> If it is so bad to build an own root class, the language should provide
> one which must be used. And the language should forbid the creation of
> another root class.
Objective-C's philosophy is to place few compiler-based restrictions on
yoru code, and let you shoot yourself in the foot if you want. There are a
ton of things that will crash or break but which will compile without so
much as a warning. Apparently this is one of them.
What is the practical difference between a root class with a bunch of
ivars, and a root class with no ivars and a subclass of it which has all
of your ivars? Splitting this into two classes seems like it would avoid
all of your problems and not break anything.
|
|
| | From: | Tilo_Prütz | | Subject: | Re: gcc+GNU-runtime: classes responding to instance methods | | Date: | Sat, 20 Nov 2004 14:30:15 +0100 |
|
|
| Michael Ash wrote:
>
> What is the practical difference between a root class with a bunch of
> ivars, and a root class with no ivars and a subclass of it which has all
> of your ivars? Splitting this into two classes seems like it would avoid
> all of your problems and not break anything.
Finally I've done so. And of course: I can live with it :).
greetz
>tilo
|
|
