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 <rony.flatsc...@wu.ac.at
> <mailto:rony.flatsc...@wu.ac.at>> 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
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
