[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

Re: rewriting proxies' sending half



> Assuming it is, here's my modified approach:   I use MarkM's idea about
> putting the handleSend(...) methods in the abstract message description
> objects, then I can get rid of all the problems with using VarArgs, and
> use the other speedup ideas that Michael suggested without worrying about
> code space very much.  

Uh...

My ideas were not for speeding up the code (though that may be a side
effect).  They were for shrinking it.

> [] it looks there are only 20 abstract signatures that ever
> get used out of about 700 methods.  That means that the space that
> the handleSend messages use doesn't matter much, and I can worry
> about speed there instead.  
> 
> So, in addition to the list Michael gave, I get to add 20 versions
> of handleSend() each with a specific (not VarArgs) signature.
> Each of those uses the calls he listed for CommXcvr, unless there
> are places I decide to go for clarity instead of conciseness.

Though the hybrid approach can produce the smallest code in the proxy
objects, it requires manual intervention if a new signature occurs.
The approach I outlined is nearly as small, and requires no intervention.

If it were just us, I'd probably say "go with the small one".  But this
is a tool that is intended to be used by our developers.  We should
avoid any solution that requires them to learn yet another piece of the
guts of our code as a prerequsite to writing their own, especially one
that would give them a mysterious link failure the first time they used
a signature that we didn't.

So unless we can come up with a way to generate all the signatures
automatically, preferably with the existing tools or some upgrade of
them, I'd prefer to go with the sometimes-slightly-larger, but completely
automatic, solution I outlined - then go to the other solution if the
space saving is not sufficient.

	michael