From: Rick M. <obj...@gm...> - 2012-08-22 13:38:10
|
On Wed, Aug 22, 2012 at 9:25 AM, Mike Cowlishaw <mf...@sp...> wrote: > ** > > > On Wed, Aug 22, 2012 at 8:26 AM, Mike Cowlishaw <mf...@sp...>wrote: > >> >> Treating .nil like NaN is an interesting model. Worth thinking through, >> I'd >> suggest (including .nil \= .nil) ... >> > Not a good idea on this last one...this feature request exists because of > some unexpected side effects of "if a = .nil" comparisons. Always having > .nil never be equal to itself would break a lot of programs! > > Have to take your word for it on that .. but it may be the only way to > have a consistent 'story', rather than special cases scattered throughout > multiple classes. That's [partly why] NaN \= NaN came to be; it was the > only closed system that worked. > > What's really changing here is not the general behavior of the comparisons, but rather the comparison methods of the string class. This just comes into effect when the left term of the operator evaluates to a string object. The current behavior is to that if the right term is not a string object, then the string version is requested (which potentially raises a NOSTRING condition) and the comparison is done using the string version. The NOSTRING condition has a very high astonishment factor for anybody who uses SIGNAL ON ALL. A comparison like "if a == .nil" triggers that because of the coercion rules, while "if .nil == a" does not because the NIL object is the one fielding the method call (that uses the default object compare, which is identity based). About once a year or so, someone opens a bug against that behavior. An frankly, the first form "if a == .nil" is the more natural way of coding this. Even though I understand what is going on under the covers and that there is additional overhead involved in using this, I still preferentially code it this way. This seems like a situation that needs fixing. And we've already had two positive votes for this feature in just the one week that the voting feature has been available. The biggest issue then, is really how to deal with the other comparisons. Consensus seems to be leaning toward making them always return .false...I think I'm ok with that. Rick > > But yes, needs of existing programs are paramount. > > Mike > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > |