Rony,
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.
Rick
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
