Ruby User Group??

Mon Mar 25 18:50:02 2002

--=-/sFPLPll/EUEdQoPtdsf
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Sorry its taken so long for me to reply. I'll try to set aside some time tonight to really think this though and provide some code. 

Carl P. 

> 
> Form form  (unique class)
> Forms < Array (different unique class, derived from type Array)
> 
> Form form = forms.first();
> 
> "=" is not an equality operator, but a *conversion* operator (must convert 
> from class Forms to class Form?!) in this case?! :)
> Therefore, (form != forms.last()) is always true...unless, of course, the 
> conversion is implicit when testing for inequality!?
> 

Again huh???. I think what he did was create an instance of the Form
Object called form and set it equal to the first form in the forms
collection "forms.first()" He then test to make sure that form is not eq
to forms.last(). Does whatever he is doing then increments the form (I'm
guessing here I haven't looked back at the code). 

Yes we can agree that its a bad example, to much of the implementation
isn't shown and like I said before there are several ways to make Java
cleaner than he insinuated. However I do agree with his general point
that Ruby is a cleaner way to implement OO. 

> Do you see the problem in extending Array yet?  If Forms is a 
> specialization of Array simply to hold Form objects, the [] operator makes 
> much better sense.
> 
> Form[] forms
> forms.first()
> forms.last()
> ...etc.

But he wanted to add his "do_each" method to the class. Personally I
think I would have overloaded the each method but I'd have to look over
the code again to be sure. 

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

> 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
> 
> The scoping of the "instance" versus "local" variables are a bit ambigous 
> to me, though I guess that the "name" passed in the initialization function 
> and the "class variable?" (dereferenced by?) @name isn't too hard to grasp. 
>  The problem I'm having I guess is with "soft" typing.  The only place in 
> our class specification above, which is obviously a trivial class of no 
> real value, that our "name" member (class attribute) is declared is in the 
> ctor, and can be any type.  Of course, let's say that (for the sake of 
> argument) that we use this as follows:
>

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

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="") 

--=-/sFPLPll/EUEdQoPtdsf
Content-Type: text/html; charset=utf-8

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
 <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
 <META NAME="GENERATOR" CONTENT="GtkHTML/1.0.1">
</HEAD>
<BODY>
<PRE>Sorry its taken so long for me to reply. I'll try to set aside some time tonight to really think this though and provide some code.

Carl P. 

&gt; 
&gt; Form form (unique class)
&gt; Forms &lt; Array (different unique class, derived from type Array)
&gt; 
&gt; Form form = forms.first();
&gt; 
&gt; &quot;=&quot; is not an equality operator, but a *conversion* operator (must convert 
&gt; from class Forms to class Form?!) in this case?! :)
&gt; Therefore, (form != forms.last()) is always true...unless, of course, the 
&gt; conversion is implicit when testing for inequality!?
&gt; </PRE>
Again huh???. I think what he did was create an instance of the Form Object called form and set it equal to the first form in the forms collection &quot;forms.first()&quot; He then test to make sure that form is not eq to forms.last(). Does whatever he is doing then increments the form (I'm guessing here I haven't looked back at the code).

Yes we can agree that its a bad example, to much of the implementation isn't shown and like I said before there are several ways to make Java cleaner than he insinuated. However I do agree with his general point that Ruby is a cleaner way to implement OO.

<PRE>&gt; Do you see the problem in extending Array yet? If Forms is a 
&gt; specialization of Array simply to hold Form objects, the [] operator makes 
&gt; much better sense.
&gt; 
&gt; Form[] forms
&gt; forms.first()
&gt; forms.last()
&gt; ...etc.</PRE>
But he wanted to add his &quot;do_each&quot; method to the class. Personally I think I would have overloaded the each method but I'd have to look over the code again to be sure.

<BR>
&lt;snip&gt;
<BR>
Bird vs rock example
<BR>
&lt;/snip&gt;
<BR>

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.&nbsp;

<PRE>&gt; class Name
&gt; &gt; def initialization(name)
&gt; &gt; 	@name = name
&gt; &gt; end
&gt; &gt; end
&gt; &gt;
&gt; &gt; in this case you have three &quot;names&quot; one Class one local paramiter (yes
&gt; &gt; initialization is the constructor). and one instanstance varable. Since
&gt; 
&gt; The scoping of the &quot;instance&quot; versus &quot;local&quot; variables are a bit ambigous 
&gt; to me, though I guess that the &quot;name&quot; passed in the initialization function 
&gt; and the &quot;class variable?&quot; (dereferenced by?) @name isn't too hard to grasp. 
&gt; The problem I'm having I guess is with &quot;soft&quot; typing. The only place in 
&gt; our class specification above, which is obviously a trivial class of no 
&gt; real value, that our &quot;name&quot; member (class attribute) is declared is in the 
&gt; ctor, and can be any type. Of course, let's say that (for the sake of 
&gt; argument) that we use this as follows:
&gt;</PRE>
First off &quot;dynamic&quot; type doesn't equate to &quot;soft&quot; type. In that if name is a String then it must act as a string until its declared to be 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). 
<PRE> 
&gt; class LastName &lt; Name
&gt; def initialization(name)
&gt; @name = name
&gt; end
&gt; end
&gt; 
&gt; Does the same &quot;name&quot; used to initialize/construct LastName get passed in on 
&gt; the initializer of the Name parent? ...since no &quot;no args&quot; default 
&gt; constructor is declared or apparently implemented?
&gt; </PRE>
No. Since you dont' have a constructor that accepts no args name *has* to be set

<BR>
myFirstName = Name.new(&quot;Carl&quot;)&nbsp; # name eq Carl and print name.type would give me a String 
<BR>
myLastName = LastName.new(&quot;Parrish&quot;) #name has be reset to eq Parrish 
<BR>

<BR>
Now had we declared LastName to be like this 
<BR>

<BR>
class LastName &lt; Name 
<BR>
def initialization(@name=name) 
<BR>
end 
<BR>
end 
<BR>

Then you could get some really weird side effects going. but typically you would use that format to do something like this

<BR>
class Lastname &lt; Name 
<BR>
&nbsp;&nbsp;&nbsp; def initilization(name=&quot;&quot;) 
<BR>
&nbsp;&nbsp;&nbsp;&nbsp; 
<BR>

<BR>

<BR>

<PRE><A HREF="http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel"></A></PRE>
</BODY>
</HTML>

--=-/sFPLPll/EUEdQoPtdsf--