Ruby User Group??

[Rob Wehrli]

> Carl Parrish wrote:
> 
> <snip>
> Bird vs rock example
> </snip>
> 
> Okay I think I can say that I agree with your overall statement.
> However I see basic object types (ie Array, Hashes, Interger, and
> Strings) as being basic building blocks and therefore I don't have too
> much of a problem extenting them. No a *big* deal anyway If I was part
> of a team that felt like you do. I'd just add an Array to the Forms
> class.

Your apparent "eagerness" to "extend" String (or any "basic type" class,
whether an array or a hash) by creating a derived class of its type does
not "extend" it at all, rather it *basterdizes* it in the (not yours,
but you apparently support it) "Forms < Array" example...

Every car has a name, right?  Car < String because a name is really a
String when memory is allocated?  Forms is NOT an Array.  That's why
Java and C++ "work" properly, because of the "[]" operator, which
invokes the Array class to create an array of objects of whatever type
is parsed out being associated with the operator.

A "Collection of Form objects" is not a kind of array object in terms of
being a derivative of Array.  It doesn't extend it.  While the operator
[] may conveniently do the same basic thing that inheritance does, it is
NOT acceptable to pass in a type of Forms (assuming Forms < Array)
wherever an Array might otherwise be expected.  In fact, assumedly, a
real "array of Forms" would only permit Forms objects.  A subclass of
Array would permit any object permissibly stored in an Array.  "Class
casting" it into a new name and, consequently, a new type, does nothing
more than change the NAMING CONVENTION by which it is expected to be
used at the level of the programmer and not at the level of the
compiler/interpreter.  Such are very poor choices made by programmers
who would otherwise consider themselves OOers.  It is, in fact, a *very
big deal* IMHO...elsewise we essentially have Birds that are Rocks and
vice versa...unpredictably "showing up" in code.  C++ will gladly allow
you to do the following:

class Bird : Rock
{
};

Of course, to the mechanized robotic rock crusher that is programmed not
to kill, passing the Bird instance in on the following:

RockCrusher::Crush( Rock *p_rock );

...would create something of a problem when:

Bird *p_b = new Bird();
RockCrusher rc;
rc.Crush( p_b );

...

However, if you write this out in code, C++, Java, and I'm guessing,
Ruby, will gladly let you pass the Bird (err, rock pointer) to the rock
crusher.  While no one really cares *that much* about the stinking bird
pointer anyway... (snicker) the illustration of the point should be
clear.  (Of course, a cast is made that strips off the relevant aspects
of the type-specific derived class when downcasting, but it still should
serve to illustrate why a bird is not a rock :)

> 
> First off "dynamic" type doesn't equate to "soft" type. In that if
> name is a String then it must act as a string until its declared to be

*NO*  It is a "soft" type because it is NOT a hard type.  That is, the
type is not known until runtime.  OK...conversely, it is NOT known at
compile time!  Take the class definition below!  "name" is NOT a string
until the initializer is called with a string argument!  HOWEVER...we
may very well try to use "name" as a string in our implementation. 
Granted, I suspect that Ruby has some more well-defined type management
system than noted here, BUT, if the following is a valid class
definition, it certainly suggests SOFT types to me!  What else does
"dynamic" type mean?  Let's take the converse using strictly typed Java.

public class LastName
{
  LastName( String name )
  { ... }
}

We KNOW that name will always be a String object unless some ruthless
casting operation casts its type into oblivion...which, in Java at
least, is not possible, since strings are immutable.  So what is "soft
typed" if Java is "hard typed?"

> of another type. The advantage here is that I don't have to create a
> brand new constructor if I also want Name to be able to hold an
> instance of a class called Name. (well actuall in this trivial example
> I would have to twick it a bit but in real world I wouldn't).
> 
> 
> > class LastName < Name
> >   def initialization(name)
> >    @name = name
> >   end
> > end
> >
> > Does the same "name" used to initialize/construct LastName get passed in on
> > the initializer of the Name parent? ...since no "no args" default
> > constructor is declared or apparently implemented?
> >
> 
> No. Since you dont' have a constructor that accepts no args name *has*
> to be set

My point EXACTLY!  I'm guessing that Ruby doesn't allow inheritance in
classes without noargs ctors?

EG:

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

class LastName < Name
end

How can a "noargs" class construct if its parent requires an arg?


> 
> myFirstName = Name.new("Carl")  # name eq Carl and print name.type
> would give me a String
> myLastName = LastName.new("Parrish") #name has be reset to eq Parrish
> 
> Now had we declared LastName to be like this
> 
> class LastName < Name
> def initialization(@name=name)
> end
> end
> 
> Then you could get some really weird side effects going. but typically
> you would use that format to do something like this
> 
> class Lastname < Name
>     def initilization(name="")

...which, I'm hoping is really the PURPOSE of a default constructor :)

> 

...all this Ruby madness...I dunno.  I can't imagine that its class
libraries (API) are so much more robust than the many years of ultra
popularity achieved by Java's...especially with millions of programmers
beating on them...and, if Java "ain't it"...I'll probably be
"officially" sticking with C and C++ when not down at the assembler
level :)

Take Care.

Rob!