What special Characters are allowed in Smalltalk Instance Variable Names and Methods?
Asked Answered
B

2

5

I remember seeing a method somewhere that actually allowed only letters 'Uppercase', 'lowercase', numbers and the underscore in the name, but I can't find it again for the life of me.

Are any other characters allowed?

Byran answered 17/2, 2015 at 18:7 Comment(0)
B
5

If you want to check which Characters are allowed in selector names you could use the RefactoringBrowser scanner and evaluate:

RBScanner isSelector: 'invalid@Selector'.
RBScanner isSelector: 'ValidSelector123_test'.
RBScanner isSelector: '111selector123_test'.

the same applies to instance variable names

RBCondition checkInstanceVariableName: 'validInstVar' in: UndefinedObject.
" true, valid instance variable name "
RBCondition checkInstanceVariableName: 'super' in: UndefinedObject.
" false, super is a reserved word in Smalltalk "
RBCondition checkInstanceVariableName: '' in: UndefinedObject.
" false, empty instance variables are not allowed "
RBCondition checkInstanceVariableName: 'Invalid' in: UndefinedObject.
" false, instance variable must start with lowercase character "

or class variables

RBCondition checkClassVarName: 'invalidClassVar' in: UndefinedObject.
" false, because class variables must start with uppercase "
RBCondition checkClassVarName: 'super' in: UndefinedObject.
" false, the same "
RBCondition checkClassVarName: '' in: UndefinedObject.
" false, empty Class variables are not allowed "
RBCondition checkClassVarName: 'Valid' in: UndefinedObject.
" true, a valid class variable "
Bushel answered 18/2, 2015 at 4:50 Comment(2)
Wow... it even has to begin with a lowercase letter. Hmmm... thank you!Byran
Selectors starting with a capital letter are valid. The general rule is that selectors must start with an alphabetic character and follow with 0 or more digits or alpha, except for binary selectors that have to be a sequence of !%&*+,-/<=>?@\~|. You can check this in RBScanner initializeClassificationTable.Professor
C
3

While the OP most likely meant "what is allowed in the regular parsable syntax", I think it's instructive to point out that the "Smalltalk Textual Language" is just an intermediate text representation to get to an object model. If you're willing to be creative, you can actually do things that the syntax with its goals of parsing simplicity would find difficult to support.

For example, you can have methods which start with numbers:

Object methodDictionary at: #1a put: (Object >> #yourself) copy.
Object new perform: #1a

Why have strings that start with numbers, when you can just use numbers directly?

Object methodDictionary at: 42 put: (Object >> #yourself) copy.
Object new perform: 42

Or how about just empty strings?

Object methodDictionary at: #'' put: (Object >> #yourself) copy.
Object new perform: #''

Your browser may or may not deal gracefully with these methods being added to your system.

Similar manipulations can be done with instance variables.

Cymose answered 18/2, 2015 at 17:16 Comment(5)
Excellent contribution. Let's add that you could also modify the selector ivar in the new method so that it corresponds to the key. This, however, is not mandatory.Professor
@LeandroCaniglia What would "modifying the selector ivar to correspond to the key", instead of the value I presume, actually achieve? What is stored in the key and value fields, respectively?Byran
In Smalltalk methods are stored in MethodDictionaries, a special kind of Dictionary where the keys are Symbols and the values are CompiledMethods. Usually the key is the selector of the CM, however, as Travis shows in his examples, that is not mandatory: the copy of Object>>#yourself is a CM with selector #yourself that is being associated to other keys such as #1a, 42 or #'' (note also that 42 is not even a Symbol!). The method will work anyway, even thought that's not the usual arrangement. My comment was about changing the selector of the copied method.Professor
@LeandroCaniglia, CompiledMethods don't have a selector ivar. Pharo stashes the literal of the selector in the method byte codes (no clue why). VisualWorks has a binding back to the class, and looks up the key of the method. In VW, the selector would have just tracked automatically. In Pharo, you'd definitely have to do some interesting juju to get the selector updated (at bare minimum smash the literalAt:).Cymose
You are right. Note however that there is a selector ivar in Dolphin and VSE (not sure about other dialects.) As you point out, in Pharo the selector is in the method's literal frame, I guess, for fast retrieval; which btw is very similar to having it in an ivar. Anyway, in Pharo your examples will answer with #yourself if you send them the selector message, even though they are not associated to that key in the MD.Professor

© 2022 - 2024 — McMap. All rights reserved.