From: hipster <hipster@...4all.nl>
Date: 2000-07-21T09:27:28+02:00
Subject: [ruby-talk:04156] Re: Tryit (The Ruby Yielding Innovation Toolkit)

On Thu, 20 Jul 2000  11:42:55 -0700, Charles Hixson wrote: [bigsnip]
> > > Given Ruby's ability for introspection a kind of `RubyBean'
> > > assembler comes to mind for the design/programming bit. A UML-like
> > > graphical representation of class lattices would be really
> > > cuspy...
> >
> > I'm not familiar with JavaBeans, although them seem like a powerful
> > tool. Does anyone have any detailed ideas for RubyBean architecture?
> >
> 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.

Taking this one step further, and keeping the earlier remark about
distributed components in mind, we could think about an Enterprise
JavaBean-like architecture (Enterprise RubyBeans, nifty ;). In this
architecture there is a third party -- the Transaction Manager -- that
instantiates components and gives out remote interfaces to (remote)
clients. The TM also governs the persistence of components, transactions
over components, database connection pooling, component caching etc etc.
This TM itself can be distributed and uses a naming and directory
interface for housekeeping stuff and magic names/numbers (JNDI).

I'm currently doing Java and EJB's for a living and I know one thing for
sure: if I could switch the whole mish mash to a Ruby equivalent I
wouldn't hesitate one microfortnight.

But I'm diverging here...

This project gets more and more interesting, but I agree with Conrad,
that after an initial brain storming phase, we should aim for a simple,
realistic v1.0 spec, paying a lot of attention to an extensible
architecture all the way.

Michel