[ruby-talk:04159] Re: Tryit (The Ruby Yielding Innovation Toolkit)

hipster wrote:

> ...
> > I think that the main thing that JavaBeans do is store the current
> > values of the object variables packed into the same file as the
> > tokenized code.  This is like storing an initialize section with the
> > object that can be reconfigured before being saved with the current
> > values. Given the pieces that are already present it doesn't *seem* to
> > be too much of an extension of what is already done.
>
> I think you mean object serialization here, what we can do right now
> using the Marshal module.
>
> In my view, the most important thing for a bean architecture is the
> specification of the interface that defines a bean. This enables tools
> like tryit to be a host for (and manipulate with) any kind of class, as
> long as it implements the bean interface. Given the dynamic nature of
> Ruby, a basic bean interface could even be dynamically
> {class,instance}_eval'd into components that don't implement a bean
> interface.
>
> ...
> Michel

Well, it's not just serialization, as there are tools that can reset the
parameters, but essentially so.  And if one has ha marshaled object in a
file (if marshaling is the same, then one must be able to pack several
discrete objects into the same file.  And modify them and resave the
modified version), when one re-loads it I suppose the specs for the object
are made available.

Ruby has a problem that Java doesn't because the specs for an individual
object can be different from those of the class, so the specs probably
wouldn't really be known until the object was loaded, though I suppose that
one could end the file with a index that contained the specs/location of
each object stored within it.  Or, possibly better, the whole mess could be
stored as a zip archive with 0 compression (i.e., the same format as a jar
file), and the specs could be in a separate directory, possibly a dual
hierarchy with one side carrying specs for the file and the other side
carrying the file.  This is rather like the manifest file that the JavaBeans
carry, but a bit more extreme, as the whole directory structure would be
mirrored.  I'm not sure of the details of the implementation, but the
benefit of using the ZIP archive format is that this is an already solved
problem, so someone could just grab the code and slap it in.  I suppose that
one could use a gz archive format, as KDE and Gnome seem to be able to open
them on the fly, but I think that I've normally seen more hesitation in the
opening of those (probably uncompressing) than in the opening of Jar->Zip
files.

As for the format in which the specs are stored, I favor using as close to
the internal representation as is practical.  But in keeping with the idea
of a "bean", it shouldn't be dependent on external-to-the-file definitions.
OTOH, I would like this file to be able to contain essentially arbitrary
files, though perhaps in a separate node off the root of the tree.  And
special provisions for the source of class definitions would be nice, also
(sort of like the VisualAge repository).  Not that I think that these should
be required, but that they should be written into the file format definition
as "optional annexes".  And a retargetable "Main application" link.  This
would support a standard way of packaging Ruby applications for
distribution, and would ameliorate the install problems that are so common.
At, of course, the cost of an increased size.  So it would be nice if there
were also a standard file layout (with optional retargeting) for unpacked
code. (E.g., you take the zip file and you unpack it to the root of your
local ruby compiler tree, preserving file path information when present).

Of course nothing here would support unpacking two different routines that
happened to have the same name (e.g., StrLen) in the same path (e.g.,
user).  If there is a decent way to handle that, then I don't know it.  The
closest that occurs to me is the Java project path.  That's not perfect, but
it pretty good.  The directory nesting gets deep, and hard to follow.  It's
really a good thing that they have JavaDoc to at least attempt to keep
things sorted out.  OTOH, Eiffel's documentation tools are probably better,
but depend more on system integration.  JavaDoc just needs so specially
formatted comments.  Eiffel requires that the system understand the
structure of the code.  Not unreasonable, as I think that it uses the
compiler parser to extract information like what routines are present, what
are the parameters, what are the ancestors, etc.  But a lot more complex
than a simple text processor like JavaDoc.

-- (c) Charles Hixson
--  Addition of advertisements or hyperlinks to products specifically
prohibited