Parrot-0.0.1

[Christopher B. Browne]

On Sun, 29 Aug 1999 22:09:50 -0500 (CDT), Skip Montanaro <skip at mojam.com>
posted:
>    Alexander> The problem as I see it is that the descriptive language is
>    Alexander> not the primary tool: once you've generated your GUI source
>    Alexander> code (eg., in Python), you're separated from the original
>    Alexander> script. There's no way to re-generate the GUI framework and
>    Alexander> preserving your logic -- because there is no separation here
>    Alexander> between presentation and code. You assume they're be
>    Alexander> intermingled.
>
>It's doable.  OMTool (Jim Rumbaugh's work at GE CRD before leaving to join
>Rational) was perfectly happy to regenerate C/C++ code skeletons the user
>had already modified and get the guts put back where they belonged.
>
>One solution here would be to have two files, one that's a GUI description
>and one that's an implementation file for one of the N backend languages.
>The GUI description would indicate the name of the callback function and
>generate code to call it.  The definition of the callback would be in an
>entirely different file.  

>The user should never need to edit the generated code.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

That is the *crucial* key to the use of these sorts of automated code
generation tools.  There *MUST NOT* be any good reason to directly edit
the code that is generated, so that it may be treated as a mere byproduct
that may be regenerated upon need.

The situation represents one where it would be Highly Desirable to use
some sort of "stub generator," ideally one that is largely
language-independent.

ILU is probably the most-developed example of such, as well as just about
any CORBA implementation.  g-wrap is a Guile-oriented scheme not unlike
this that is intended to allow declarations of interlinkages between
Scheme and C.

In the case of CORBA, there's an additional cost of having to have
requests head out to the ORB and back, which may be an unacceptable cost.

In any case, whichever sort of "stubber" might be used, it is very
important to have a clear separation between "code that needs to be
written," and "code that is automagically generated."
-- 
When replying, it is often possible to cleverly edit the original
message in such a way as to subtly alter its meaning or tone to your
advantage while appearing that you are taking pains to preserve the
author's intent.  As a bonus, it will seem that your superior
intellect is cutting through all the excess verbiage to the very heart
of the matter.
-- from the Symbolics Guidelines for Sending Mail
cbbrowne at ntlug.org- <http://www.ntlug.org/~cbbrowne/corba.html>