Hmmm, just started making the changes for this feature, only to discover
that the bypass for ==, \==, et al was already implemented! I'm sure I was
probably the person who made this change, but I don't remember when. I
think this feature still needs a complete implementation though.
Rick
On Wed, Aug 22, 2012 at 9:37 AM, Rick McGuire <object.r...@gmail.com> wrote:
>
>
> On Wed, Aug 22, 2012 at 9:25 AM, Mike Cowlishaw <m...@speleotrove.com>wrote:
>
>> **
>>
>>
>> On Wed, Aug 22, 2012 at 8:26 AM, Mike Cowlishaw <m...@speleotrove.com>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
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
>>
>
------------------------------------------------------------------------------
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
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
