Re: [Oorexx-devel] [DISCUSS] adding class constants

[Mark M. <mie...@gm...>]

On 10/13/07, Rick McGuire <obj...@gm...> wrote:

> I'm starting to look forward to the next release, and the first thing I've
> starting hacking at is a DOM XML implementation.  The W3C DOM standards
> define a number of named constants that are part of the API.  To match the
> standard, we should keep the same numeric values, but it would be nice to
> have symbolic ones as well. To implement these, I've been coding a bunch of
> tiny methods like this:
>
> ::METHOD ELEMENT_NODE class
>   use strict arg -- enforce argument limits
>   return 1
> ::METHOD ATTRIBUTE_NODE class
>   use strict arg
>   return 2

Yes.  Over the years since I first wrote an ooRexx program, (back on
OS/2) I've toyed with various schemes to employ constants in my
programs.  Most of them worked okay for the one program, or some
programs, but were hard to apply in a generic way.

So, I'm all for adding some solid support to make it easy, (easier) to
use constants.  In relation to what Lee brought up, two of the things
I have worked on recently could really use constants.  The System
Metrics have about 90 constant values for indexes.  And, for key
presses, there are all the virtual key constants.

> It would be nice if we did something handy like is done with the ::ATTRIBUTE
> directive, but oriented toward constant values:
>
> ::CONSTANT ELEMENT_NODE 1
> ::CONSTANT ATTRIBUTE_NODE 2
> ...
>    if .Node~ELEMENT_NODE == type then ...
>
> Using the hardcoded environment name, or I could use a non-hardcoded name
> using
>
>   if self~class~ELEMENT_NODE == type then ...
>
> It would be nice if I could just use
>
>   if self~ELEMENT_NODE == type then ...

One of the things about constants is you usually end up with long
names.  Then when you tack on the class name etc., your lines of code
start getting long.  Eliminating the "~class" helps that.

> ...
> Where two methods are defined, one at the class level and one at the
> instance level.  If that's the desired behavior, it certainly makes a
> ::CONSTANT short hand even more important.
>
> This is a "next release" item, so we've got plenty of time to discuss how
> this should work.  Thoughts?

I'm all for some solution for this.  The ::CONSTANT short hand is a good start.

--
Mark Miesfeld