From: Rick M. <obj...@gm...> - 2013-11-24 16:06:46
|
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? Rick |
From: David A. <w.d...@gm...> - 2013-11-24 16:23:51
|
I am in agreement with Rick on this one. I like number 2 as the best solution but I can live with number 1. David Ashley On Sun, 2013-11-24 at 11:06 -0500, 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? > > > Rick > ------------------------------------------------------------------------------ > 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 > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel |
From: Rony G. F. <Ron...@wu...> - 2013-11-24 16:43:29
|
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 |
From: Mike C. <mf...@sp...> - 2013-11-24 17:15:15
|
Another approach would be to transform any 'iffy' names to a form that is acceptable. When writing MemoWiki I discovered that file names have various OS-implied restrictions that conflict, and that in practice the only non-alphanumeric characters allowed are '-' and '_' -- so I used '_' for blank and '-' as an escape character to introduce hex for anything else. |
From: Rick M. <obj...@gm...> - 2013-11-24 17:23:17
|
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 <Ron...@wu... > 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 > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > |
From: Mark M. <mie...@gm...> - 2013-11-24 17:21:25
|
I'm good with number 2. Although, I don't have a compelling need to use a digit as the first character of a class, so any of the options would be fine with me. 3DGlasses is a pretty good name. ;-) -- Mark Miesfeld On Sun, Nov 24, 2013 at 8:06 AM, Rick McGuire <obj...@gm...> 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? > > Rick > > > ------------------------------------------------------------------------------ > 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 > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > |
From: Rick M. <obj...@gm...> - 2013-11-24 17:42:22
|
On Sun, Nov 24, 2013 at 12:21 PM, Mark Miesfeld <mie...@gm...> wrote: > I'm good with number 2. > > Although, I don't have a compelling need to use a digit as the first > character of a class, so any of the options would be fine with me. > 3DGlasses is a pretty good name. ;-) > In my case, I was using a class name of 3DMedusa, which is the name of a Sudoku solving technique. There was a pretty high-astonishment factor when my program was unable to resolve this class name. It took me some time to figure out what was going on, and I'm probably a bit more knowledgeable than your average oorexx user ;-) Rick > > -- > Mark Miesfeld > > > On Sun, Nov 24, 2013 at 8:06 AM, Rick McGuire <obj...@gm...>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? >> >> Rick >> >> >> ------------------------------------------------------------------------------ >> 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 >> Oor...@li... >> 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 > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > |
From: Rony G. F. <Ron...@wu...> - 2013-11-24 17:26:47
|
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 <Ron...@wu... > <mailto:Ron...@wu...>> 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 > |
From: Rick M. <obj...@gm...> - 2013-11-24 17:38:47
|
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 <Ron...@wu... > 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 < > Ron...@wu...> 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 > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > |