A couple of additional findings on the potential numeric rule. Under the
current rules, the environment symbol ".3DGlasses" is not be an environment
symbol, but '..3" is one. Under the rule I just proposed, the first would
become valid, but the second would suddenly be invalid. I'm thinking a
better rule would be "if the symbol begins with a "." and is not a valid
Rexx number, then it is an environment symbol". The scanner already
determines the first of these, but applies "the second character not a
digit test" to the non-numeric symbol value.
Rick
On Sun, Nov 24, 2013 at 12:27 PM, Rony G. Flatscher <[email protected]
> wrote:
> Rick,
>
> On 24.11.2013 18:23, Rick McGuire wrote:
>
> This has nothing to do with method names, only with class definitions and
> lookups. Your example is already something that works with method
> invocations. And "an environment literal string" could potentially cause
> breakage with existing programs as that has an already defined meaning
> today.
>
> oh, o.k., thank you!
>
> In that case I would prefer #2 as well.
>
> ---rony
>
>
>
>
>
> On Sun, Nov 24, 2013 at 11:26 AM, Rony G. Flatscher <
> [email protected]> wrote:
>
>>
>> On 24.11.2013 17:06, Rick McGuire wrote:
>>
>> Ran into this little glitch this morning with a program I was writing. I
>> created a class that started with the characters "3D", and was getting an
>> error when i tried to instantiate it because the corresponding environment
>> symbol resolved to a string value. I opened bug 1212 to address this.
>>
>> One of the first things I encountered was the docs for environment
>> symbols, which requires that the first character not be a digit (section
>> 1.13.6 in the reference). So, in a sense, this is working correctly,
>> although with a high astonishment factor. The ::class directive does not
>> place any restrictions, allowing you to create classes that you can't look
>> up via environment symbols. For example,
>>
>> say .context~package~classes["INVALID NAME"]~new
>> say .3dglasses~new
>>
>> ::class 3DGlasses
>> ::method init
>> say "Creating 3D Glasses"
>>
>> ::class "invalid name"
>> ::method init
>>
>> say "Creating a funny instance"
>>
>> It seems like a reasonable thing to create a class name like 3DGlasses,
>> but the current definition of environment symbols pretty much precludes
>> this. I see a number of possibilities here;
>>
>> 1) Do nothing other than add some documentation to the ::CLASS
>> directive explaining the implications of the name choice.
>>
>> 2) Change the definition of environment symbol to a restriction on the
>> second character to "the remaining part of the symbol cannot be a valid
>> Rexx number'.
>>
>> 3) Implement restrictions on the ::CLASS directive such that the name
>> must be a valid environment symbol.
>>
>> I'm not terribly fond of solution 3), I'm sort of in favor of 2, but
>> can live with 1.
>>
>> Thoughts?
>>
>>
>> How about allowing an "environment literal string" (a leading dot,
>> immediately followed by a literal string) which would yield the value to
>> look up in the environment? The string would be uppercased (like in the
>> method name case) and then used for a lookup in the environment.
>>
>> This would follow along the lines of the definition of a method name,
>> which usually is a symbol, however it also can be a literal string (that
>> seems to be uppercased), e.g.:
>>
>> o1=.test~new
>> o1~"one with non-symbol chars ..."
>>
>> ::method "one with non-symbol chars ..."
>> say "method 'one with non-symbol chars ...' could be invoked"
>>
>> The above program works and yields:
>>
>> method 'one with non-symbol chars ...' could be invoked
>>
>> ---
>>
>> Applying "environment literal strings" to your example might then look
>> like:
>>
>> say ."3dglasses"~new
>>
>> ::class 3DGlasses
>> ::method init
>> say "Creating 3D Glasses"
>>
>>
>> This would allow to express any class name that is not a symbol (even
>> ones that contain blanks), keeping the current definition of "environment
>> symbol", yet being able to refer to any class name via the environment.
>>
>> ---rony
>>
>
>
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up
> now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> Oorexx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
