Ruby User Group??

[Rob Wehrli]

Carl Parrish wrote:

> The class "Form" is being declared here
> 
> class Forms < Array

Of course, this isn't very "Oopness-correct" :)  A Forms (yes, plural)
is a kind of an Array?  Java's array mechansim(s) are entirely more
appropriate, IMHO.

for a class Form an array of Form objects becomes Form forms[]...which
is infinitely more OOP-correct than a Forms isa Array.  I think that the
LJ author wrote without a clue :)  Way too many people really DO NOT get
OO...but can use it just enough to be really dangerous...

> 
> just means that Forms is a subclass of the Array Object. The keyword
> yeild here is used just like CLU version. It means that everytime it
> encounters it yield use it as if the method was called again. In trivial
> examples it doesn't seem to have much use (after all why not simply
> *call* the method again). However in code blocks, like it is here, its
> very useful. In this example since each_do has an "each" call putting
> yeild in the block makes the method recursive. My point is that once you
> know the syntax it's really easy to look at that block of code and
> "know" what it's doing unlike a lot of recursive methods where I have to
> look twice.

Recursiveness in code is oftentimes difficult to determine and even
harder to determine the effect of when debugging.

> 
> >
> >           class Song
> >                def initialize(name, artist, duration)
> >                  @name     = name
> >                  @artist   = artist
> >                  @duration = duration
> >                end
> >              end
> >
> > Is this Visual Basic or what?
> 
> This is like saying
>   my($name) = name
> in perl

Not that I know anything about PERL :)  My point in the above class Song
implementation/declaration! was that by itself, even if a trivial
example, it violates the basic OO rule of encapsultation.  Song is a
pure data class and doesn't have any methods (except initialize,
assumedly a default constructor? ...perhaps the only ctor?).  The
enviable goal of encapsulation is to encapsulate the attributes and
operations necessary to faciliate the object within the object.

In this short brush-up-against Ruby, it prompts a question being how
does package management work?  If the definition and implementation are
combined, there seems at least a basic need for a package metaphor
similar to Java's.  I'm tired of looking at it already :)  Just another
script syntax?  What is so great about it?  The ability to understand
what the code does from looking at it?  It doesn't appear to give any
level of protection to members.  What about constant and/or static
members?  I'm guessing that in the Song class above that the types of
name, artist and duration are "strings" or they are classes?  @ is the
"this->" resolution operator?  Is the following different or even
allowed?

class name
  def initialization(name)
    @name =name
  end
end

What is a string and what is a class?  Certainly the underlying types
must somehow be differentiated?

And FINALLY (snicker)...in what language is the interpreter written? :)


> 
> I'm always interested in feedback btw.
> 
> Carl P.
> 

Take Care.

Rob!