What is the meaning of numArgs
ncellier at ifrance.com
Sat Jul 28 02:21:33 UTC 2007
Bert Freudenberg a écrit :
>> "But does anyone knows what the following cases are meaning?"
>> #'a:b:c' numArgs = 1.
>> #'a::bc' numArgs = 1.
>> #':abc:' numArgs = 0.
>> #'::abc' numArgs = -1.
>> #':abc' numArgs = -2.
>> #':::' numArgs. "make your guess here"
> I guess these are remnants of the experiments with alternate syntaxes,
> which allowed leading and trailing parts of identifiers IIRC (e.g., "if
> ... then ... end" would be a valid expression and the selector
> ":if:then:end" - I'm making this up, but something along the lines was
> - Bert -
Ah, thanks, i was willing to put some tests because i made cosmetic
changes for WideString cases.
But I cannot reasonnably write a TestCase if i do not understand the
I note thanks to Boris that VW has a pre-requisite:
VW numArgsFor: aString
"Answer the number of arguments that the argument
requires if it is interpreted as a message selector.
We will assume that the string has been validated as
a reasonable message selector by some other means
But no such assumption is explicitly made in Squeak, on the contrary -1
is returned if not-well-formed selector detected:
"Answer either the number of arguments that the receiver would take if
considered a selector. Answer -1 if it couldn't be a selector. Note
that currently this will answer -1 for anything begining with an
uppercase letter even though the system will accept such symbols as
selectors. It is intended mostly for the assistance of spelling
SOME COMMENTS ON COMMENTS:
I also note that Squeak comment is not up to date since
'A:' numArgs = 1, not -1
That's the problem with comments. They are not automatically checked by
test cases, only by humans. They are usefull. But code has higher priority.
Also note that most senders are rather checking selector numArgs before
a (receiver perform: selector) despite the warning about method
intention. I do not know what the warning was intended for (maybe a
warning for method not being reliable, spell-checking-assistance being a
VW is clear, single syntax, no validity check.
Squeak, not so. Not aware about alternate syntax, and not perfectly
understanding english, my expectations are that i will get -1 whenever
the selector is not well formed.
With my expectations, there is a semantic conflict:
Trusting regular syntax i will expect #':a:b:' numArgs = -1.
Someone else trusting alternate will expect #':a:b:' numArgs = 1.
To resolve the conflict and support several syntax we would have to ask
numArgsFor: to a Parser.
But my expectations are wrong.
"Answer -1 if it couldn't be a selector. "
has not the same value as:
"Answer -1 if it is not a valid selector. "
I now understand it as a fuzzy logic, will answer -1 in some cases but
not always, and that's what it does indeed.
These experimental remnants makes the whole system:
- harder to understand
- harder to maintain
- weaker (some miss-interpretations and wrong expectations like mine can
easily introduce flaws).
I would tend to simplify and loose some unused features.
Eventually, we could clean-up experimental remnants.
Eventually we could enforce these three rules:
- no $: first
- no consecutives $:
- $: should be in last position if any
Eventually, we could do nothing and live with the statu quo. I do not
However, would i be the manager of the official image that i would
arbitrarily impose this: someone interested in this feature writes a
test case that explains the extension within the next X months, or the
feature will be removed.
More information about the Squeak-dev