Ruby User Group??

[Carl Parrish]

> 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.
> 

Ops sorry. But again why I think we need an "offical" language. @name =
name says to make a instance varible called name and give it the value
of the local varible name. Once I got used to it I like this format
because just by looking at it I know that @name is a instance varable,
without having to know anything else about the code. @@ in front would
have been a Class varible and $ would have been a global. And if it
starts with a Capital letter then its a constant	


I didn't realize that there were several point you brought up in the
last email that I didn't address. (trying to type these out fast). 

Here they are:

>We now have to consider that "each" is a keyword meaning elements in an
>array?  I love "each do | form |"  Read that as "each do pipe form
>pipe" or is that supposed to be the absolute value of form?  Sorry, but
>I still don't see what makes Ruby so special.  AND the author of the LJ
>article is obviously WRONG since the code above is NOT Java-like, since
>Java can not convert (class) form to a boolean to make the while
>conditional true/false, though C can if "form" is really a pointer to a
>Form class.

each is not really a "keyword", actually almost everything in Ruby can
be overloaded so there really doesn't seem to *be*  many "keywords".
However it is a default method of Array and used pretty commond so it
work's like a keyword. And I think that's why Forms extended Array (just
so he could get the "each" method). Ruby coders seem to prefer this
method over for loops and now that I'm getting used to it (and code
blocks, which work different in Ruby than in any other language I can
think of) I can see that its both more powerful to use this syntax and
easier to read. (however unlike python you can still do a for loop in
the form I'm familar with). Also  (form != forms.last()) does eval to a
bool so I'm not really sure what you're talking about there.  


On Wed, 2002-03-20 at 16:06, Rob Wehrli wrote:
> 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...
> 
True that, and I may be one of those people. However in this case the
Class of Forms is really just a Collection of (I'm assuming) Form. So I
don't really see a problem in his using an extend Array class to hold
it.  


> 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.
Well there are Modules (I think more like python's). and Namespaces
though I admitt I don't quite understand them in Ruby yet. 



  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
No this would not be allowed. All class names have to be constant and
therefore start with Caps (I know that *really* bothered me for a bit
but really I always names Classes with Caps anyway so didn't *really*
change anything just seemed to not be as powerful). So your code would
have to change like this

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

in this case you have three "names" one Class one local paramiter (yes
initialization is the constructor). and one instanstance varable. Since
Ruby is Dynamically typed they could be of any type. Though I guess you
*could* do this

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




> And FINALLY (snicker)...in what language is the interpreter written? :)
> 
And yes of course the interpreter is C