[Xotcl] Very severe limitation in XOTcl

[SImon Millward]

Isn't it fair to say that by design, any dynamic language has such possible traps and pitfalls... (although this one is especially awkward). You don't need to try very hard to make TCL fall over in all sorts of ways like this.

The question I always ask my teams when something like this comes up is
- Why didn't the unit tests catch it
- What 'stock' unit test will we add in future to catch it

> It's very easy to miss, as it's quite natural for a coder to pass in arguments directly to constructors.

Its quite hard to miss if you TDD it...

Over a fairly short period of time you soon have a nice set of unit test classes that always try an throw up these sorts of problems. Probably about half a dozen small tests that pump in 'iffy' stuff to a method covers it.. and because of the beauty of typeless (or stringly typed) languages than can be readily used without modification

Anyway, just my thoughts.

Regards
Simon


On 4 Aug 2010, at 13:14, Kristoffer Lawson wrote:

> 
> On 4 Aug 2010, at 12:37, Gustaf Neumann wrote:
> 
>> 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.
> 
> Yes, this is the first time I came across this, and it took a while to debug :-) However I'm almost certain a lot of code I have stored around is susceptible to the same thing. That's the danger with this: it's very easy to get by by just passing in arguments in the normal way, and then end up with a severe security hole. It's very easy to miss, as it's quite natural for a coder to pass in arguments directly to constructors.
> 
>> 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.
> 
> I think dropping it is a good decision. It'll be interesting to see what the next XOTcl is like.
> 
> How much complexity will the new version be adding? The beauty with XOTcl, especially the earlier versions, was that despite the power of it, it was quite simple (unlike C++). Much like Tcl itself: power, but simplicity. I would be concerned if that gets lost along the way.
> 
> -- 
> Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/
> 
> _______________________________________________
> Xotcl mailing list
> Xotcl at alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl