>
> directoryseparator -- same value returned by .File~separator
Rick, above isn't yet implemented (REXX-ooRexx_5.0.0(MT)_64-bit 6.05 9 Oct
2014)
On Sun, Sep 28, 2014 at 3:18 PM, Rick McGuire <object.r...@gmail.com> wrote:
> 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
>
>
------------------------------------------------------------------------------
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
