What is the meaning of numArgs

"i can understand valid selectors:"

"Unary:"
#yourself numArgs = 0.

"Binary:"
#'**' numArgs = 1.

"Keywords"
#at: numArgs = 1.
#at:put: numArgs = 2.


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


"Nicolas"

On Jul 28, 2007, at 1:48 , nicolas cellier wrote:

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 -

VisualWorks' interpretation if anyone cares,

#yourself numArgs = 0.
#'**' numArgs = 1.
#at: numArgs = 1.
#at:put: numArgs = 2.
#'a:b:c' numArgs = 2.
#'a::bc' numArgs = 2.
#':abc:' numArgs = 3.
#'::abc' numArgs = 3.
#':abc' numArgs = 2.
#':::' numArgs = 4.

Not a whole lot better, but at least no negatives in the list ;)

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: [hidden email]
[mailto:squeak-dev-

Bert Freudenberg a écrit :
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