oh, o.k., thank you!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.
On Sun, Nov 24, 2013 at 11:26 AM, Rony G. Flatscher <Rony.Flatscher@wu.ac.at> wrote:
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.
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 initsay "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.
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.:
The above program works and yields: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"
---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.