[Xotcl] Very severe limitation in XOTcl

[Gustaf Neumann]

Dear Kristoffer and all.

yes, this is a part, where xotcl was criticized for in the past - not 
without reason.
The problem is a tribute to invocations to methods with a variable number
of arguments in the dash notation (calling methods with zero to n 
arguments)
without knowing the length of the argument list (which is in the general
case not possible in Tcl due to args). For me it is sometimes surprising,
how well it works even for large projects, with several thousand lines
of code and many developers involved. The XOTcl serializer
uses the dash notation as well, but analyses the arguments and adds the 
lists
as needed.

Anyhow, the next incarnation of XOTcl, on which we are hard working
right now, has this feature dropped, and provides a much more orthogonal
parameterization for objects and methods. As the new framework
supports multiple object systems in one interpreter, one can use classical
XOTcl and the new object system in parallel.

best regards
-gustaf neumann

Am 04.08.10 11:07, schrieb Kristoffer Lawson:
> On 4 Aug 2010, at 10:08, mail at xdobry.de wrote:
>
>    
>>   Foo new [list -init $a]
>>      
> Thanks yes, as tired as I was last night, I didn't come up with that. The thing is, that basically has to be done all the time if you are passing in variables. Obviously any time you pass user-generated string, but also in other cases as well when you can't be 100% sure of the content (and often you can't). I probably have hundreds of places where this can cause a bug, at best, and a security hole, at worst.
>
> Using [list -init<vars>] all the time does not, to me, sound like elegant programming. I use the dash feature much more infrequently than just plain instantiation. Besides, you are at risk even with the dash feature, if you pass it an argument...
>
> I'm not exactly sure even how I would solve this for XOTcl. Any special argument syntax is always going to be at risk. As mentioned, even arguments to the dash values are risky. In that respect I would consider dropping the whole feature. It's that risky.
>
>