Tim,

In certain places it is critical that the class of an object cannot be
forged. Otherwise you would need to know beforehand which methods you can
send to proxies and which ones you don't. However, I agree that there's no
need for having #class generate that byte code so some really long and
annoying selector (like primitiveUnforgableClassOfObject) or somesuch might
be in order.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org
> [mailto:squeak-dev-admin at lists.squeakfoundation.org]On Behalf Of Tim
> Rowledge
> Sent: Saturday, January 05, 2002 7:25 AM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Does #class deserve to be a very-special shortcut bytecode
> anymore?
>
>
> Whilst discussing delegation and proxying with Stephen P, the
> subject of
> #class came up. Since #class is implemented in practice via a very
> special case bytecode it is a royal pain for proxy work since
> you can't
> override it very easily.
>
> Now, #class is not a message one should send very often so one must
> wonder if it is actually sensible to have the vm do this. I looked up
> all the users of the relevant bytecode and there are in fact 1143 of
> them in a upgrade#4478 image. Random sampling suggests that a large
> percentage of those are case where the writer of the method
> ought to be
> soundly spanked for not factoring things properly. None of the random
> sample struck me as being cases where the performance enhancement of a
> short-circuit bytecode was interesting.
>
> We could, I suspect, convert the bytecode to at least do a normal
> message send (like nearly all the other bytecode special
> sends) and ease
> life for proxinators without any impact on performance. Can
> anyone come
> up with a really good reason for the current situation? Just
> curious...
>
> tim
> --
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> Useful random insult:- Four bits short of a full DEC.
>
>
>