From: Charles Hixson Date: 2000-07-21T08:56:06-07:00 Subject: [ruby-talk:04159] Re: Tryit (The Ruby Yielding Innovation Toolkit) This is a multi-part message in MIME format. --------------980ACF37F8850D5EE23D996E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 --------------980ACF37F8850D5EE23D996E Content-Type: text/x-vcard; charset=us-ascii; name="charleshixsn.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Charles Hixson Content-Disposition: attachment; filename="charleshixsn.vcf" begin:vcard n:Hixson;Charles x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:charleshixson@earthling.net fn:Charles Hixson end:vcard --------------980ACF37F8850D5EE23D996E--