Decided to also add majorVersion, release, and revision values to this to
return the pieces of the version number.
Rick
On Sun, Sep 28, 2014 at 7:35 AM, Rick McGuire <object.r...@gmail.com> wrote:
> The intent of this feature is to gather up all of the disparate pieces of
> information that might effect the interpretation of a program and put them
> in one place. This will be a combination of Rexx language information and
> some platform-specific information. The object will be available in the
> environment as REXXINFO and will have a bunch of read-only attribute
> methods. Methods I currently have are:
>
> package -- returns the special "REXX" package that is new in 5.0.0
> (holds all of the REXX-defined classes).
>
> digits -- the default digits setting
> fuzz -- the default fuzz setting
> form -- the default form setting
> internalDigits -- the digits setting for "numbers used internally by REXX"
> languageLevel -- The language level for the interpreter, e.g. 6.04
> version -- The interpreter version number, e.g., 5.0.0
> date -- The interpreter date
> platform -- The interpreter platform descriptor (same as the string
> returned by parse source)
> architecture -- The bit-ness of the interpreter.
> endofline -- same value returned by .endofline
> pathsepartor -- same value returned by .File~pathSeparator
> directoryseparator -- same value returned by .File~separator
> caseSensitiveFiles -- same value returned by .File~isCaseSensitive
>
> These values as intended to be for information that does not change with
> interpreter context. I considered adding address as an attribute, but that
> is something that changes based on how the interpreter is invoked. I still
> might be persuaded to add that one.
>
> Questions I would specifically like input on:
>
> 1) Not sure I like the "internalDigits" name. Anybody have better
> suggestions?
> 2) Also not sure I like the "architecture" name, since this is not really
> a hardware architecture.
> 3) An actual hardware architecture one might be nice...not sure I want to
> get into the issue of defining what is returned for that at this time.
> This can easily be added later.
> 4) Do we need some sort of byte-order indicator (i.e., endian-ness). Not
> sure what values we're return for that.
> 5) Are there any other values we might want to add.
>
> Rick
>
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
