From: Pit Capitain <pit@...>
Date: 2001-08-17T03:23:21+09:00
Subject: [ruby-talk:19914] Re: Why not?: Assigning to self

Hi all,


one last reply to several messages concerning the rectangle / 
square example:



On 16 Aug 2001, at 21:42, Dave Thomas wrote:


<color><param>7F00,0000,0000</param>> (...) what is the difference between a Square and

> a Rectangle as classes? Why differentiate? Perhaps the

</color>> underlying Shape class should have a #has_equal_sides?

> method?


Of course in this example I assumed classes Rectangle and 
Square to be different. In one of my former posts I mentioned 
method #reflection_axes, which would be different for Rectangle 
and Square. I didn't want to use #become just to get a different 
object type. I wanted to get different behaviour.


<color><param>7F00,0000,0000</param>> However, I can't see any use for 'becomes.' My bias here comes

</color>> from<color><param>7F00,0000,0000</param> the fact that in Ruby classes are not types, and types are

</color>> not<color><param>7F00,0000,0000</param> classes. (In a way it's a shame that there's a built-in #type

</color>> method,<color><param>7F00,0000,0000</param> because this is misleading.) If we had a #becomes that

</color>> swapped an<color><param>7F00,0000,0000</param> object's class, it would be a subtle but profound shift

</color>> in the<color><param>7F00,0000,0000</param> underlying language, giving classes more significance than

</color>> they<color><param>7F00,0000,0000</param> deserve.


</color>I see #become simply as replacing an object by another. No 
mentioning of classes and I think also no emphasizing on classes 
here. Maybe the example was misleading.



On 16 Aug 2001, at 22:46, Dave Thomas wrote:


<color><param>7F00,0000,0000</param>> I still don't see this. There's no difference between your two

</color>> classes<color><param>7F00,0000,0000</param> except they sometimes become one another.


</color>I thought it was self explaining that I only showed the code that's 
using the #become method, not the whole classes. By the way it's 
the same technique that's used in the excellent pickaxe book. The 
authors tried to make it easier for the reader to follow the topic 
currently under discussion :). Maybe I should have mentioned this 
explicitly.



On 16 Aug 2001, at 23:17, Piers Cawley wrote:


<color><param>7F00,0000,0000</param>> Once again, I point at my 'state machine' example as an

</color>> instance where<color><param>7F00,0000,0000</param> 'becoming' could be useful. The

</color>> 'square'/'rectangle' thing is, as you<color><param>7F00,0000,0000</param> point out, silly.


</color>Bang!


Still I don't think so.



On 17 Aug 2001, at 0:30, Niklas Frykholm wrote:


<color><param>7F00,0000,0000</param>> I think #become is harmful when it changes the interface of an object.


</color>See below.

<color><param>7F00,0000,0000</param> 

> The purpose of #become is to change an object's behavior without having to

> manually change all references to it.


</color>Yes, thats what I meant.


> But if the interace of the object

<color><param>7F00,0000,0000</param>> changes, we will still have to do some sort of manual update to

> make sure that everywhere a reference to the object is used, we are aware

> of its new interface.</color> So nothing is really gained. At the same

> time,<color><param>7F00,0000,0000</param> a lot is lost. Since objects can change interface "under our

</color>> feet" it becomes<color><param>7F00,0000,0000</param> harder to read programs.


</color>I don't see this. As has been mentioned before in this thread, you 
can change the interface of an object already by other means 
(singleton classes). Quite a few ruby programs do this, and I can't 
remember somewhere updating references.


I agree though that it can make programs harder to read. But I 
doubt that #become would be harder to read than the use of 
singleton classes, and I think noone would want to loose these.


<color><param>7F00,0000,0000</param>> (...)

 


> Then there is the question of whether the langauge should try to enforce a

> good coding style, or allow everything and let the users care about shooting

> themselves in the foot. Should we allow #become even if we cannot restrict

> it to "safe" cases?


</color>As I said in my original post, I only would want an implementation 
of #become if it is safe. I earn my living by software development for 
too long a time that I would want to introduce quick'n'dirty hacks, 
particularly not at such vital things like meta protocols.


<color><param>7F00,0000,0000</param>> Then of course, there is the implementation issue. How much work would it be to

> implement #become, and is that time perhaps better spent on developing other

> parts of ruby?


</color>I wholeheartedly agree. In fact, this rectangle / square thread has 
lasted longer than I anticipated, and I hope that it will end soon.


> There aren't that many programs that can make good use of

<color><param>7F00,0000,0000</param>> #become (most people have a hard time coming up with good examples) and

> everything that can be done with #become can be done in other ways, without too

> much of a hassle -- either by returning new objects (if there are not multiple

> references to the object) or by implementing a delegator mechanism:


</color>Maybe you are right. I will keep looking for other good examples in 
my next programming tasks. And because I don't think I'll write a 
graphic editor in the near future, it will certainly not be the rectangle 
/ square example. Still I think it's a good one :)


Thanks for all your input,

Pit

<nofill>