Re: Strange Things...

[R James Noble <kjx@comp.vuw.ac.nz>]

Dave:

> First, I think the ability to have both public and private slots
> of the same name in the same object is a problematic part of the
> language, and am not too surprised it gives you problems too.
> We should probably treat it as bad style for now.

Err - I don't think the slots are in the same actual object, just a
public slot is in an object inherited by another object containing a
private slot of the same name. (I guess this is what you meant).  I
guess the rules could be changed so if a private slot is found at the
highest priority, a noPublicSelector error could be generated.

> Second, you want to avoid the reflective primitives _AddSLots: etc
> as much as possible and use DI and one-slot'ers instead

Well, there always "William R Burdick"'s strange "build an cons-cell
list of extra parents" technique I remember from this list last year.
I think going to one-slot'ers is a win because the main allMessages
objects can use constant pointers and the compiler should inline it
all away: the someMessages at least won't have to recompile them.

The overhead is in processing the caught sends anyway: so the overhead
of DI in the some messages is probably less than the hash table
lookups I do now even for messages I'm not interested in.

Urs:

> ... No, the code would actually NOT be shared! The source code is shared,
> of course, but the compiler would still generate code for each
> particular receiver, i.e. each someMessages object.

Of course - Now I think again, I'm claiming this as a feature of the
implementation. Actually I'm hoping the compiler will inline all the
allMessage/someMessage overhead into the object that is being monitored.

> In general, all of the following will be slow:
> - huge objects (7000 slots...)

This is why allMessages is currently divided into categories of 70-100
slots each. Is there an optimal size for objects, or some limit above
which things become especially slow?

>  - frequent programming operations

This should only bite when the user requests an object be monitored
(OK) or when cloning a monitored object. Cloning can happen
transparently inside particular object's implementations (especially
dictionaries) for this I'll just live with the overhead.

>  - megamorphic sends (sending "isString" to every object in the
>   world)

(I though I wasn't supposed to send isString to ANY object :-) I'm
reasonably clever about this: I start with objects that inherit from
"traits immutableString" and work from there. But there's lots of
string manipulation testing strings to see whether they are valid Self
selectors.

Given the optimisations performed on dynamic inheritance, perhaps I
will try this for the someMessages implementation.

Once it is clean enough to run without too much special scaffolding, I
can release this part of the system and let others try it.

as ever - thanks again both for information and encouragement!

James