On Wed, May 27, 2015 at 5:58 PM, Erich Steinböck <erich.steinbo...@gmail.com > wrote:
> Just committed RexxRef documentation for RexxInfo class (and environment > variable). > A local RexxRef build is available in sandbox/erich/docs/build > <https://sourceforge.net/p/oorexx/code-0/HEAD/tree/sandbox/erich/docs/build/> > for anyone interested. > > Two questions: > > 1. > >> Also not sure I like the "architecture" name, since this is not really a >> hardware architecture. >> > Would renaming "architecture" to "addressingMode" better match the intent? > I was never all that attached to architecture, but also not fond of addressingMode either. wordSize is another possibility. > > 2. > Access to .RexxInfo is handled differently as that of e.g. .RexxContext. > Both are classes where we don't want the user to create instances. But: > > whereas the RexxContext class is made available as normal through > .environment (i. e. .RexxContext), and an instance (.Context) is made > available through "special" global variable .Context, > > for RexxInfo its only instance is made available through .environment as > .RexxInfo (not a class!) and the .RexxInfo class can't be referenced > directly. > > Might it be better to make those two more similar? > No, I don't think they should be. RexxContext has many instances and .Context is just the lookup for the instance associated with the current context. RexxInfo is a special thing with just a single instance and there's no point in adding sucking up an additional name from the environment just to make it similar. Rick > > > Erich > > > > On Thu, Oct 9, 2014 at 1:46 PM, Rick McGuire <object.r...@gmail.com> > wrote: > >> Oops, the method was implemented but I missed adding to the method >> table. Its in now. >> >> Rick >> >> >> >> On Thu, Oct 9, 2014 at 5:39 AM, Erich Steinböck < >> erich.steinbo...@gmail.com> wrote: >> >>> 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 >>> >>> >> >> >> ------------------------------------------------------------------------------ >> 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 >> >> > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > >
------------------------------------------------------------------------------
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
