From: Bob Hutchison <hutch@...>
Date: 2002-01-25T22:49:26+09:00
Subject: Re: OOP UI Design

On 1/24/02 8:30 PM, "James Britt (rubydev)" <james@rubyxml.com> wrote:

Regarding Holub's article... I read it a long time ago and do not recall
being particularly impressed with that particular effort. MVC has worked for
me for years, but it isn't framework isn't as simple as some would like to
think. Trying to design a class from a single point of view is a luxury,
trying to design a framework where classes are used for one thing only (e.g.
a GUI) is lunacy, critiquing a language convention based on a single use
(e.g. a GUI, in this case a certain *kind* of GUI) isn't helpful. Accessors
are accessors, syntax won't solve the problem Holub is referring to -- there
are other considerations that would support the statement that Eiffel/Ruby
way is better. If I recall, Holub was mostly complaining about the practice
of automatically defining accessors for all internal state, and he has a
point (but he goes too far with it I think, claiming 'able to be  misused'
implies 'evil' is hyperbole). However, in Java a 'bean' has to satisfy a
particular architectural requirement and consequently all persisted state
has to have accessors defined that follow a specified convention. There is
no requirement at all for accessors on any other kind of data, and nothing
required at all of classes that are not beans, and nothing says *you* have
to use them in your programs. Java has a really interesting and
underutilised property: any instance of a GUI (say a dialog box and all its
contents for example) can be serialised, and so persisted, without the need
for java source code being written to describe the GUI -- and support for
this is where the bean requirement in Java GUIs seems to have originated.

> 
> What are the risks in using Java applications as a design base when attempting
> to build
> something in Ruby?  There have been a few discussions here where someone
> advocates
> building the Ruby version of [SomeJavaApp].  Given that a language guides you
> into certain
> design decisions that you might not have made in another language, at what
> point does
> copying a Java application become counter-productive when using Ruby?
> 
> Put another way, what (if anything) do Java developers do that a Ruby
> developer wouldn't,
> because Java prevents or hinders a design path that is available in Ruby?
> 

Here is an incomplete list based on a recent experience.

1/ Ruby has the ability to define blocks that can be yielded to, and the
built-in Ruby classes use them. This affects how you design classes, both
the interface you provide and in the structure.

2/ The java package system isn't the same as what Ruby provides with modules
and files

3/ Ruby has no type declarations, so things like heterogeneous collections
are possible; you cannot overload method names, you should double dispatch

4/ Ruby classes and modules can be extended by loading a file (not just
created), and that that file can contain executable code. Ruby objects can
be extended with specific behaviours.

5/ Mixins are not available in Java

There are others that I'll think of on the walk to the subway :-) Actually,
I had not thought of compiling a list of what I came across. I can probably
explain why/how these should be considered.

Each of these will impact porting of Java to Ruby, and if they are not
addressed you'll have a poor Ruby implementation. There are other features
of Ruby that a Java application probably won't make use of (e.g. aliasing,
retry) but that I don't think not using will lead to necessarily bad Ruby
code.

Cheers,
Bob