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 
> supported).
> 
> - 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 
meaning.

FACTS:
-----

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
	first."

But no such assumption is explicitly made in Squeak, on the contrary -1 
   is returned if not-well-formed selector detected:

Squeak numArgs
	"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 
correction."

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 
bug-tolerant feature?).

RATIONAL ANALYSIS:
-----------------

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.

PERSONNAL OPINION:
-----------------

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.

LOGICAL CONCLUSION:
------------------

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 
much care.

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.

Nicolas