Proxy as subclass of nil

I created a class Proxy as a subclass of Object and it works great.
Implemented #doesNotUnderstand: and a few other methods.  Subclassing
Object works fine, but I would like to get rid of the overhead from
inheritance from Object.

I moved the class to subclass nil. So far so good. But, when my code
tries to instantiate an instance of Proxy, the image crashes.

Therefore, I moved Proxy back as a subclass of Object just to keep
things working. My question is quite simple:

Is there a way to subclass nil for Proxy? More importantly, how to
subclass nil and correctly instantiate an instance of Proxy without
crashing the image?

Andy or Blair, will a primitive of some type be needed to create the
instance? I am at a complete loss here on how to get this to work.

Any or all suggestions or experiences subclassing nil are welcome.
Thanks,

Pax

On 13 Jan 2005 19:38:03 -0800, Pax <[hidden email]> wrote:

> I created a class Proxy as a subclass of Object and it works great.
> Implemented #doesNotUnderstand: and a few other methods.  Subclassing
> Object works fine, but I would like to get rid of the overhead from
> inheritance from Object.

You can subclass ProtoObject instead.

--
Regards
HweeBoon
MotionObj

> Is there a way to subclass nil for Proxy? More importantly, how to
> subclass nil and correctly instantiate an instance of Proxy without
> crashing the image?

Is there some reason not to use ProtoObject?  It should make your life
easier.  I have a proxy of same (I do not recall whether it ever used
nil as super class).  I also make use of a few flags in the
_InstanceBehaviorMasks pool, and copied a few callers of primitives, but
I wanted finalization, etc.  A search of the archives should get you going.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Yar Hwee Boon[*] wrote[**]:

> > I created a class Proxy as a subclass of Object and it works great.
> > Implemented #doesNotUnderstand: and a few other methods.  Subclassing
> > Object works fine, but I would like to get rid of the overhead from
> > inheritance from Object.
>
> You can subclass ProtoObject instead.

Agreed; that's what ProtoObject's for.

I thought I'd add that you shouldn't need to do anything very special to make
this work even if you prefer to use your own direct subclass of nil.  I use one
(it dates back to before ProtoObject existed) that provides implementations of
just ~~, ==, #debugPrintString, and #doesNotUnderstand, and that works OK.  And
I don't really see why ~~ and == should be needed (at least not to avoid
crashes) but I can't be bothered to remove them and see if it breaks.

    -- chris

(
[*] I am getting increasingly uncomfortable typing out "Yar Whee Boon" in full
every time, if feels so unfriendly, is there a shorter form you'd prefer ?

[**] In just 10 seconds -- if the posts' timestamps can be believed -- I am
impressed !
)

On Fri, 14 Jan 2005 10:05:39 -0000, Chris Uppal  
<[hidden email]> wrote:

> [*] I am getting increasingly uncomfortable typing out "Yar Whee Boon"  
> in full
> every time, if feels so unfriendly, is there a shorter form you'd prefer  
> ?

Heh, and after typing in full for a few times you got it wrong this time  
:) Anyway, "Yar" would be what you know as last name. "Hwee Boon" would be  
my first name. So Hwee Boon will do. You only get to type 4 letters less  
and I wouldn't mind if you prefer HweeBoon instead.

> [**] In just 10 seconds -- if the posts' timestamps can be believed -- I  
> am
> impressed !

It says 15 here. Just so happens I have my client opened, and to double  
that - I am using ProtoObject right now :)

--
Regards
HweeBoon
MotionObj

Hwee Boon,

> > [*] I am getting increasingly uncomfortable typing out "Yar Whee Boon"
> > in full
> > every time, if feels so unfriendly, is there a shorter form you'd prefer
> > ?
>
> Heh, and after typing in full for a few times you got it wrong this time
> :)

BLAST!


> Anyway, "Yar" would be what you know as last name. "Hwee Boon" would be
> my first name. So Hwee Boon will do.

Noted, thanks.


> You only get to type 4 letters less
> and I wouldn't mind if you prefer HweeBoon instead.

Oh, I don't mind typing one extra letter.  If I need to keep it short, I'll
just call you "you" instead ;-)

    -- chris

On Fri, 14 Jan 2005 10:05:39 -0000, "Chris Uppal"
<[hidden email]> wrote:

I don't understand very well what this ProtoObject is for and why it's
not part of the Object hierarchy. Could someone please enlighten me?
O:-)

Thanks

On Fri, 14 Jan 2005 17:02:44 +0100, Fernando <[hidden email]> wrote:

> I don't understand very well what this ProtoObject is for and why it's
> not part of the Object hierarchy. Could someone please enlighten me?

The class comment -

     ProtoObject is an abstract class that can be used as a basis for  
creating a variety of "stub" subclasses.  It supplies the minimum protocol  
that might be useful for any such stub in order that inspection and  
debugging may successfully take place.

I'm not sure if there is any special reason why it should be used. But for  
me, I'm using it simply because it is a simple and "light" object (like  
why you chose nil).

--
Regards
HweeBoon
MotionObj

Ok, I moved Proxy to subclass ProtoObject and all is well; no image
crashes.

Regards,

Pax

Fernando wrote:

> > > You can subclass ProtoObject instead.
> >
> > Agreed; that's what ProtoObject's for.
>
> I don't understand very well what this ProtoObject is for and why it's
> not part of the Object hierarchy.

The reason it's not under Object is in order to avoid inheriting all the Object
methods.  Subclassing nil is usually used if you want to create some sort of
object that uses MessageNotUnderstood handling (providing a special
implementation of #doesNotUnderstand:) in order to implement some kind of
dynamic behaviour.

For instance the proxies (sorry "stubs";-) that Esteban has been discussing,
which wait till they receive any message, and then turn themselves into the
"real" object before attempting to handle it.

The problem with that technique is that it only works for messages that the
object doesn't already understand, so to use it safely/properly you have to
ensure that your object doesn't inherit any methods from a superclass such as
Object.  Hence you don't give your class any superclass, i.e. -- as they say --
you "subclass nil".

But the problem with /that/ is that the system (debuggers, inspectors, basic
error handling, etc) require a certain base set of methods in order to function
at least minimally.  So you have to work out what the minimal set is.  Or,
alternatively, subclass the class that OA have provided for just that purpose
which (presumably) has just the right minimal set.  That is class ProtoObject.

    -- chris

Chris,

thanks for the informative explanation regarding "stubs" and
subclassing of Object VS nil. Much more enlightening than discussing
the length of ones name (grins).

Pax