Le Dimanche 19 Février 2006 01:42, Dan Ingalls a écrit :
> >There is no fix for this problem. In Squeak, the number of parameters for
> > a method invocation is limited to 15.
>
> I think there may be a relatively simple solution for extending the number
> of arguments to 31.  I realize that it is only a factor of two, and folks
> may consider it not worth worrying about this unless all limits are to be
> relieved but, if I'm correct, I'd be remiss if I didn't point this out.
>
>  It looks to me like the method headers can take another bit of argCount as
> is, and the double-extended-do-anything bytecode can specify up to 31
> arguments on a send.  I added the DEDA bytecode for other reasons, and may
> just never have bothered extending argcount at the time, figuring such code
> is, um, not generally found in Smalltalk programs.
>

Very true, lot of arguments surely indicate lack of an abstraction level 
(think of creating a new class).
This was just in case of external world linking. We cannot change external 
world, we must adapt.

> So  if I'm not mistaken about the argCount bits in the method header and
> the DEDA bytecode, all that remains is a bit of compiler work and a few
> methods in CompiledMethod which shouldn't add up to more than an hour or
> two for someone who knows the territory.
>
> FWIW
>
>  - Dan

I have another idea (workaround): fake this limit passing a single array 
argument:
 - transform method calls (recvr key1: arg1: ... keyn: argn) into (recvr 
key1:key2:keyn: {arg1. arg2. ... argn})
 - transform method implementation: argj would be replaced by (arg1 at: j)
This can be done transparently at code generation from ParseNode.
Some class like MessageAsTempNode can easily do the work.

So i started inquiring bytecode generation and found this: the DEDA you are 
speaking of also have a limitation to 256 variables. And i did not see these 
limitations enforced anywhere in the code.
Only the single byte code limit is tested for in LeafNode>>#code:type:, and 
the code for DEDA is temporarily encoded (type*256+index). Should index 
overpass the 256 limit, there might be strange results, changing the type of 
operation and probably crashing the VM...

Protecting this code would be easy
(index > 255) ifTrue: [self error: 'bycode limit exceeded'].

Maybe i missed a protection elsewhere ? I will try to exhibit a test case 
latter.