Re: [MMXX-dev] Intro and interest

[Luca R. <lj...@us...>]

On 4/21/2000 5:02 AM, Frank V. Castellucci (fr...@co...) 
shared his wisdom:

>Shadow
>------
>The idea of a shadow is, as I am sure you are aware, a Proxy. In the GoF
>Patterns, in semantic understanding, etc. Consider changing the
>terminology as it would be more familiar than Shadow. Consider other
>familiar terms in documentation along the lines of delegation,
>marshalling, etc. From a proxy perspective there is also the issues of
>performance and scalability to consider.

Good point. If you'd be willing to help reengineer the entire vocabulary
that'd be great. I agree that this has to be done pretty early, since
changing names gets harder as we go on. Steven has also offered to work on
the docs/test projects so I'm sure he'll be interested in this :-)

However, it'd be nice to 1) make all the needed changes in one shot so 
that
we can keep the development sidetracking to a minimum, and 2) at the same
time, adjust most symbol names that need to be adjusted accordingly (and
possibly do the overdue syntactical changes too,) since the adv. docs 
can't
'branch away' from the terminology in the source at this stage. Perhaps we
can build a renaming to-do list in a piecemeal fashion?

My only question on 'proxy' in particular is whether 'proxy' is as
well-suited as a modifier and verb as it is as a noun, namely because MMXX
'shadows' both real classes and other shadows, so in the new terminology
it'd have to 'proxy' both real classes and other (stacked) proxies. If
this doesn't abuse 'proxy' as seen in the literature then it's definitely
a go. Since we're at it, is there a better word for 'peer'? On a
historical note, i originally picked 'shadow' and 'peer' to get some 
mental
separation from 'stub class', 'skeleton', etc. as seen elsewhere.

I like 'marshall' and 'marshalling' as well, indeed the symbols right
now abuse the word 'stub' all over the place mostly because it's short.

>I assume that exception management will be delegated back through the
>implementation->proxy bridge somehow.

Yes, I'm working on adding exception management right now. Exceptions are
caught by the callee stub, encapsulated in MMXXException's (if they're
not already) and re-thrown by the caller stub. Within a day or so I'm
going to post again asking for suggestions about the controversial
aspects here, and as I'm sure you've guessed there's quite a few. :)

BTW Frank, I've added you to the developer list on SourceForge
(however useful that might be at this stage.)

Ciao!
Luca