Hi Erich, The Docs look good.
I also think 'architecture' is not intuitive. I'm happy with 'wordsize', although I often hear 'bitness'. On the same subject, I think the 'date' attribute needs qualifying. I think that replacing .rexxInfo~date with .rexxInfo~buildDate would read a lot more clearly. Jon On 27 May 2015 at 23:09, Rick McGuire <object.r...@gmail.com> wrote: > > > 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 > >
------------------------------------------------------------------------------
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
