------ art_101106_4698561.1216727590648 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tue, Jul 22, 2008 at 12:47 AM, Martin Duerst <duerst / it.aoyama.ac.jp> wrote: > At 23:51 08/07/21, Urabe Shyouhei wrote: > > >FYI, expression "true" refers to the same object on multiple invocations: > > > >irb(main):001:0> a rue > > true > >irb(main):002:0> a.instance_variable_set "@foo", ["bar", "baz"] > > ["bar", "baz"] > >irb(main):003:0> b rue > > true > >irb(main):004:0> b.instance_variable_get "@foo" > > ["bar", "baz"] > >irb(main):005:0> > > Is this an actual example shunk down, or is it just made up to > show a point? If it's the later (as I suspect), then yes, objects > such as nil and true and false are to a large extent real objects, > and so can have instance variables and so on. > I think that the real distinction in the case of dup between objects like nil, true, false, symbols and the like is not immutability, but that these objects are unique. Unique objects have the property that if two unique objects are equal they are the same object. But what we need to show that letting dup return self for true and > friends is a bad idea is not just that they refer to the same object, > but that this fact, combined with the usual use of these objects > (not some bordercase example) creates real problems. > > We have already seen three or four people tell us that they > redefine dup or create another (safer, according to Jim) method. > We have heard from several people that extending the definition of > dup wouldn't lead to problems as far as they knew. > > We haven't had anybody claim, or show us, that or how extending > dup semantics would actually cause a problem in real use. > Changing dup so that 'duplicating' a unique object returns the same object is consistent with similar methods in similar/related languages (e.g. Smalltalk's shallowCopy which is the equivalent of Ruby's dup works this way). It feels more natural to me than the status quo since it makes for less special cases (i.e. exceptions). The main argument against the change is legacy, that's the way dup has been defined in Ruby. The real question is whether the decision to raise an exception upon the attempt to dup a unique object is more useful than annoyance. I suspect that it's the latter, but that's not for me alone to say. -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/ ------ art_101106_4698561.1216727590648 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline <div dir tr">On Tue, Jul 22, 2008 at 12:47 AM, Martin Duerst <<a href ailto:duerst / it.aoyama.ac.jp">duerst / it.aoyama.ac.jp</a>> wrote:<br><div class mail_quote"><blockquote class mail_quote" style order-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class h2E3d">At 23:51 08/07/21, Urabe Shyouhei wrote:<br> <br> >FYI, expression "true" refers to the same object on multiple invocations:<br> ><br> >irb(main):001:0> a rue<br> > t; true<br> >irb(main):002:0> a.instance_variable_set "@foo", ["bar", "baz"]<br> > t; ["bar", "baz"]<br> >irb(main):003:0> b rue<br> > t; true<br> >irb(main):004:0> b.instance_variable_get "@foo"<br> > t; ["bar", "baz"]<br> >irb(main):005:0><br> <br> </div>Is this an actual example shunk down, or is it just made up to<br> show a point? If it's the later (as I suspect), then yes, objects<br> such as nil and true and false are to a large extent real objects,<br> and so can have instance variables and so on.<br> </blockquote><div><br>I think that the real distinction in the case of dup between objects like nil, true, false, symbols and the like is not immutability, but that these objects are unique. Unique objects have the property that if two unique objects are equal they are the same object.<br> <br></div><blockquote class mail_quote" style order-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> But what we need to show that letting dup return self for true and<br> friends is a bad idea is not just that they refer to the same object,<br> but that this fact, combined with the usual use of these objects<br> (not some bordercase example) creates real problems.<br> <br> We have already seen three or four people tell us that they<br> redefine dup or create another (safer, according to Jim) method.<br> We have heard from several people that extending the definition of<br> dup wouldn't lead to problems as far as they knew.<br> <br> We haven't had anybody claim, or show us, that or how extending<br> dup semantics would actually cause a problem in real use.<br> <div><div></div><div class j3C7c"></div></div></blockquote><div><br>Changing dup so that 'duplicating' a unique object returns the same object is consistent with similar methods in similar/related languages (e.g. Smalltalk's shallowCopy which is the equivalent of Ruby's dup works this way). It feels more natural to me than the status quo since it makes for less special cases (i.e. exceptions).<br> <br>The main argument against the change is legacy, that's the way dup has been defined in Ruby. The real question is whether the decision to raise an exception upon the attempt to dup a unique object is more useful than annoyance. I suspect that it's the latter, but that's not for me alone to say.<br> </div></div><br>-- <br>Rick DeNatale<br><br>My blog on Ruby<br><a href ttp://talklikeaduck.denhaven2.com/">http://talklikeaduck.denhaven2.com/</a> </div> ------ art_101106_4698561.1216727590648--