Save a slot or two, at what cost?

Hello all,

I am cleaning up some old code that uses things that you might consider
analogous to GDI objects.  It also has a parallel "description" class,
not unlike logical fonts, etc., except that they are Smalltalk objects.
  In the GDI analogy, they carry colors and other preferences, but lack
the handle, owner and stuff like that.

This stuff is old.  I probably did what I did in part thinking of
packaging.  There is a setup tool and a main app; they have always lived
in different packages, but now are accompanied by a plethora of base
packages that almost sorta make sense.  The classes of interest now live
in one particular base package shared by the deploying packages.  Any
packaging argument that might have existed is gone.

I might have also been thinking about gc efficiency: w/o the extra
slots, the objects put a smaller load in the gc.  It is also perhaps a
little cleaner to have the setup tool, which never "realizes" the "GDI
objects", unburdened by the ivs that it will never use.  However, the
object and its description are much closer in appearance than say a view
and a view resource (which are completely different beasts), and life
might be simpler if the description were in fact an unrealized object.

Bottom line: I am thinking of giving the descriptions the boot.
Recommendations for or against it will be appreciated.

Have a good one,

Bill


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

Hello all,

Any takers on this one?  I'm curious what you think.  If your reaction
is "I removed an abstraction like that once and never lived it down",
then I would ver much like to hear about it.


Have a good one,

Bill

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

Bill,

can you give a specific example?

It is my ignorance, but I cannot perfectly follow... would it mean for
graphic contexts something similar like the lazy initialization of
objects?

Thanks,
Janos

Bill,

> > Bottom line: I am thinking of giving the descriptions the boot.
> > Recommendations for or against it will be appreciated.
>
> Any takers on this one?  I'm curious what you think.

Since you ask twice, I'll risk a pop at this ;-)

You don't give a lot of detail, so it's hard to see where you are starting
from.  Call your "GDI"-like objects Realizables.  Do you have Realizables which
HAVE a Description ? Or is that a Description (may) HAVE a Realizable ?  Or is
it that Realizables are (in the sense of ISA) also <Description>s (perhaps by
subclassing, perhaps not) ?

What I'm trying to get at is are thinking of merging the two /concepts/ -- so
that <Realizable> and <Description> vanish into one new abstraction (and
therefore the code gets merged too) ? Or are you still keeping those two
concepts separate, but merging the code so there is only one kind of object
which can be used as a <Realizable> or as a <Description> according to need ?

If it's the latter, then although I might well create that kind of pattern if I
were working from scratch -- to keep things simple -- it's not so clear that
there's much to gain if you already have the separation coded.  If you have a
lot of objects which are used as <Realizable>s but never as <Description>s (or
vice versa) then that would suggest that the two "should" be kept separate.
OTOH, if you have a significant problem with code duplication -- where you have
code to handle <Realizable> in one way, and then have a (near) copy of code
doing (mostly) the same thing to <Description>, then that would suggest that
you really "should" have only one object which capable of playing both roles.

I.e. I don't know ;-)

    -- chris

Chris,

> Since you ask twice, I'll risk a pop at this ;-)

Thanks!

> You don't give a lot of detail, so it's hard to see where you are starting
> from.  Call your "GDI"-like objects Realizables.  Do you have Realizables which
> HAVE a Description ? Or is that a Description (may) HAVE a Realizable ?  Or is
> it that Realizables are (in the sense of ISA) also <Description>s (perhaps by
> subclassing, perhaps not) ?

The realizables (by sharing a common protocol, not subclassing) are
descriptions.  My hunch is that I created the descriptions to have
simpler objects (smaller STB footprint with lots of them in a file) and
due to packaging constraints, which were probably a mix of things not
working as well as they do now and (more so) lack of understanding on my
part.


> What I'm trying to get at is are thinking of merging the two /concepts/ -- so
> that <Realizable> and <Description> vanish into one new abstraction (and
> therefore the code gets merged too) ? Or are you still keeping those two
> concepts separate, but merging the code so there is only one kind of object
> which can be used as a <Realizable> or as a <Description> according to need ?

Good question.  I think I am merging the code so that the description
concept becomes redundant.  With only the realizables, they can be
lazily realized by the GUI.  As it is now, there is confusion over when
to add new items [*] _and_ when to realize them; the latter becomes easy
to do lazily if the descriptions go away.

[*] it's tricky, but I have it more or less matching the expectations of
the users.  Suffice it to say that there are identity/equality
comparisons, and "realization" state enters too.  In the current system,
that ends up being being tests on type rather than state in the proposed
solution.


> If it's the latter, then although I might well create that kind of pattern if I
> were working from scratch -- to keep things simple -- it's not so clear that
> there's much to gain if you already have the separation coded.  

The problem is that the logic is complicated by the separate objects.
At least that's my story for now :)


 > If you have a
> lot of objects which are used as <Realizable>s but never as <Description>s (or
> vice versa) then that would suggest that the two "should" be kept separate.

This is why I ask the question.  There are descriptions that never get
realized.  However, a description is really not much different from a
realizable object, with a couple fewer instance variables.  How much GC
benefit is one likely to get with a few hundred objects that exist
largely to avoid a couple of nil instance variables each?  The packaging
arguments in favor of separation are long gone.  We are down to GC,
elegance, and STB size (the latter can be measured with a little work),
and the benefits come at the expense of polymorphic lists and tests on
type :(


> OTOH, if you have a significant problem with code duplication -- where you have
> code to handle <Realizable> in one way, and then have a (near) copy of code
> doing (mostly) the same thing to <Description>, then that would suggest that
> you really "should" have only one object which capable of playing both roles.

It's more that the code has to cope with both types of objects.  The
descriptions and realiables get mixed because the users think of them
that way.  I suspect my life would be easier if I turned a blind eye to
a couple of nil instance variables that would allow a non-realized
realizable to fill the current role of a description.

Does that make it more clear?


> I.e. I don't know ;-)

Makes two of us :(

Thanks!!!!

Bill

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

Bill,

Random thoughts...

> [...] a description is really not much different from a
> realizable object, with a couple fewer instance variables.  How much GC
> benefit is one likely to get with a few hundred objects that exist
> largely to avoid a couple of nil instance variables each?

Probably negative I'd guess.  Although I doubt whether the difference is
measurable, let alone significant.


> and the benefits come at the expense of polymorphic lists and tests on
> type :(

If you are doing tests-on-type then that sounds very much as if your code
"wants" to treat them identically, but then at the last moment (as it were)
finds that it can't quite do so.  Analogy: I run a home for cats, I treat all
the cats identically, but then one day when I have to pick one up... Oops;
there's nothing to pick it up by, it's a Manx[*] cat!  I'd better use a quick,
hacky, test-on-type here, rather than opening a new home just for Manx's.  (If
you see what I mean ;-)

([*] Manx cats have no tails)


> The
> descriptions and realiables get mixed because the users think of them
> that way.

Further suggestive evidence that they "should" all be the same.


> I suspect my life would be easier if I turned a blind eye to
> a couple of nil instance variables that would allow a non-realized
> realizable to fill the current role of a description.

Maybe you could factor out the realisation data into a separate object. The
main objects would then be #realised (contains a ref to a realisation data
object), or #notRealised (contains nil in that slot).  Tidier, and probably a
little bit easier to manage, than having a sub-section of the main object that
is only used some of the time.

    -- chris