This is fairly simple to implement for the equals/not equals variants. The
real open question is how to handle the other comparisons such as >, <,
etc. These are probably VERY rare situations, but the behavior still needs
to be defined. I see three obvious paths:
1) Leave them the way they are today. For these operators, the operation
will go through the existing string conversion and perform the comparison
on the string value "The Nil Object".
2) Have them always return .false. It sort of makes sense, but it creates
some unexpected behavior such as "a > .nil" and "a < .nil" both returning
.false.
3) Make this an error. This, of course, will really break the rare
program that happens to be doing this. On the other hand, the reverse
comparison ".nil > a" IS an error today, because only the String class
implements those comparison methods.
I suspect 1) is the course that makes the most sense and will have the
least disruption. But I'm interested in opinions on this, and I may have
missed other potential solutions.
Rick
---------- Forwarded message ----------
From: Rick McGuire <bigr...@users.sf.net>
Date: Tue, Aug 21, 2012 at 4:32 PM
Subject: [oorexx:feature-requests] #473 String compares should have special
exception for .nil
To: "[oorexx:feature-requests]" <4...@feature-requests.oorexx.p.re.sf.net>
- **status**: open --> accepted
- **assigned_to**: Rick McGuire
- **pending_work_items**: --> code+doc+test
- **milestone**: --> v4.2.0
---
** [feature-requests:473] String compares should have special exception for
.nil**
**Status:** accepted
**Labels:** Classes
**Created:** Mon Jul 09, 2012 11:25 AM UTC by Rick McGuire
**Last Updated:** Mon Aug 20, 2012 03:23 PM UTC
**Owner:** Rick McGuire
Currently, the string implementations of comparison operations
unconditionally convert the right-hand-side of the comparison to a string
value. This means compares like
if arg == .nil then ....
If the variable arg is .nil, then these objects are compared directly. If
variable arg is a string value, .nil gets converted to the string "The NIL
object" and this value is compared. This has two problems:
1) There is a potential for a false positive on this compare if the string
value happens to be the string "The NIL object"
2) a NOSTRING condition is raised, which causes unexpected problems if
SIGNAL ON ANY is in use.
The workaround is to code "if .nil == arg then ..." to get .nil on the left
side of the operator. In practice, people almost universally prefer the
first form. Comparison to .nil is such an important thing on the ooRexx
language that the string class should recognize .nil as a special case and
always return .false (avoiding the NOSTRING condition as well).
---
Sent from sourceforge.net because you indicated interest in <
https://sourceforge.net/p/oorexx/feature-requests/473/>
To unsubscribe from further messages, please visit <
https://sourceforge.net/auth/prefs/>
------------------------------------------------------------------------------
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
