On Sun, Feb 12, 2017 at 10:54 AM, lb <liangbin...@126.com> wrote: > Hi Ben， > Thank you very much, your answer make me clear like water. > My question aimed on where, which type errors occur when perform a message. > My usecase. > when perform: aMessage(with a space), get DNU error , cannot find out by > eyes directly.
What is the higher level use case? For example, are you getting input from a user that you evaluate as a command in some kind of Domain Specific Language? In such a case you may be better to validate the command has no spaces closer to the UI? > > asMessage is better than asSymbol. If you don't get community support for this, you can start extending String like this for your own projects and later promote your concrete experience with it. cheers -ben > > Cheers Bing > > At 2017-02-12 00:39:55, "Ben Coman" <b...@openinworld.com> wrote: >>Hi Bing Liang, >> >>Thanks for your comments. Fresh eyes provide interesting perspectives >>on things we take for granted. >> >>On Sat, Feb 11, 2017 at 4:41 PM, lb <liangbin...@126.com> wrote: >>> Thank you, Sven >>> gradually clear. >>> 1. Symbol as String subclass, only guarantees a symbol object only one in >>> system, use ==; >>> 2. keywords (selector name method name) are spectial symbols, without >>> space >>> or forbided characters; >>> 3. perform: aSymbol, means perform: aKeyword, >> >>Not exactly. It means perform a "message" where there are three types >>of messages... >>* unary, like #printString >>* binary, like #+ >>* keyword, like #perform: or >>#subclass:instanceVariableNames:classVariableNames:package: >>having a colon appended to each keyword >> >>> Should we add asKeyword to String, >>> let >>> perform: aString asKeyword >> >>or alternatively per above... perform: aString asMessage >> >>> not >>> perform: aString asSymbol ? >> >>In the case that aString contained a space, >>presumably #asMessage would produce a runtime error in asMessage >>whereas #asSymbol would produce a runtime error in #perform: >>I guess there is a minor benefit of failing early but will that make >>much difference in practice. >>Do you have a use case where it makes a major difference? >> >> >>> At 2017-02-11 15:51:49, "Sven Van Caekenberghe" <s...@stfx.eu> wrote: >>>>Hi Bing, >>>> >>>>Yes, any character is allowed in a Symbol. There is even special syntax >>>> that allows such Symbols to be represented literally. >>>> >>>>'a b' asSymbol. >>>> >>>> => #'a b' >>>> >>>>Although it might be confusing, I don't see any problem. >>>> >>>>The concept of 'meaning' is defined by the user, the usage, not by the >>>> Symbol itself. A Symbol with a space cannot be a selector >>>> (message/method) >>>> name, but that does not mean a Symbol with a space could not be useful >>>> in >>>> some other context. >>>> >>>>> On 11 Feb 2017, at 05:56, lb <liangbin...@126.com> wrote: >>>>> >>>>> Hi, >>>>> I know Symbol is subclass of String. >>>>> Any string object can become symbol object by sending 'asSymbol' >>>>> message.. >>>>> I think symbol must has its meaning in common use, so the symbol >>>>> should >>>>> be composed of alphabet or number ‘without space“. >> >>Different domains have different common usage. >>IIUC, Smalltalk's definition of symbol is from the 1970s. >>Pharo is not overly constrained by Smalltalk traditions, but there >>must be sufficient gain to balance deviations from consistency with >>other Smalltalks. >> >>>>> >>>>> BUT There are not compliant below >>>>> 1. ' ' asSymbol >>>> no meaning >>>>> 2. '$%%&' asSymbol >>>> no meaning >>>>> 3. 'sign' asSymbol = 'sign ' asSymbol >>> false because of space. >>>>> 3. ' one two three ' asSymbol >>> I think It should >>>>> become three symbols = #one, #two, #three >>>>> >>>>> >>>>> Maybe my understanding is wrong. >> >>no problem. Being wrong is a great way to learn ;) >> >>cheers -ben >>
