No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] Very severe limitation in XOTcl
From: Kristoffer Lawson <setok_at_scred.com>
Date: Thu, 5 Aug 2010 11:38:47 +0300
On 5 Aug 2010, at 10:59, Gustaf Neumann wrote:
> In my understanding, Kristoffers point was that although he is using
> XOTcl since many
> years (i see postings from him more than 10 years ago) and although he
> is a experienced
> programmer, he was not aware of the problem with argument values
> starting with a dash
> (certainly not all, e.g. negative numbers are fine), and he was not
> aware of the escape
> mechanism (which was added to XOTcl early 2003, see Changelog).
Cheers, and apologies if any offense was caused by my postings. This just caught me completely off guard. Of course once I saw it, it was obvious what is happening, but it really is something you can easily miss, especially as existing XOTcl code out there will not generally worry about it.
> The primarily problem is external input, unfortunately, one weak element
> of most
> scripting languages. Similar problems lurk around in Tcl in scripts like
>
> set file1 -force
> set file2 -violence
> file delete $file1 $file2
Indeed. The slight saving grace for those cases is that, in practise, one tries to look more carefully before operating on any filenames passed by the user, but I agree it's quite easy to get caught out there too. Maybe Tcl should have used a different model for optional arguments (something like [file {delete -force} $file] perhaps?), but it's unfortunately difficult to turn back the clock on that...
> The case with the dash arguments in XOTcl is especially nasty to the
> unaware, since the standard configure method determines on the "-"
> (a) where the last argument list ends, and (b), what to call as a method.
> If user-data is passed to the object creation, using the list notation is
> therefore a must (as mentioned by Artur)
Yes, this is also true for setting a parameter:
Car new -doors $amount
If $amount contains a dash, it'll do a method call. Just something to be aware of. It's also not just for user-passed values either. The same could apply to random data, or binary data, or the contents of a file, for instance. Watch out if you're doing a YAML parser.
> People fully aware of the XOTcl flexibility have no big problem with this,
> since they can write their own "configure" method (this method
> implements the dash interpretation) and use this (e.g. via mixins)
> where appropriate.
Yes, if something positive has to be said then it is that flexibility. I went one further and already created a method directly into 'Class' ;-)
Date: Thu, 5 Aug 2010 11:38:47 +0300
On 5 Aug 2010, at 10:59, Gustaf Neumann wrote:
> In my understanding, Kristoffers point was that although he is using
> XOTcl since many
> years (i see postings from him more than 10 years ago) and although he
> is a experienced
> programmer, he was not aware of the problem with argument values
> starting with a dash
> (certainly not all, e.g. negative numbers are fine), and he was not
> aware of the escape
> mechanism (which was added to XOTcl early 2003, see Changelog).
Cheers, and apologies if any offense was caused by my postings. This just caught me completely off guard. Of course once I saw it, it was obvious what is happening, but it really is something you can easily miss, especially as existing XOTcl code out there will not generally worry about it.
> The primarily problem is external input, unfortunately, one weak element
> of most
> scripting languages. Similar problems lurk around in Tcl in scripts like
>
> set file1 -force
> set file2 -violence
> file delete $file1 $file2
Indeed. The slight saving grace for those cases is that, in practise, one tries to look more carefully before operating on any filenames passed by the user, but I agree it's quite easy to get caught out there too. Maybe Tcl should have used a different model for optional arguments (something like [file {delete -force} $file] perhaps?), but it's unfortunately difficult to turn back the clock on that...
> The case with the dash arguments in XOTcl is especially nasty to the
> unaware, since the standard configure method determines on the "-"
> (a) where the last argument list ends, and (b), what to call as a method.
> If user-data is passed to the object creation, using the list notation is
> therefore a must (as mentioned by Artur)
Yes, this is also true for setting a parameter:
Car new -doors $amount
If $amount contains a dash, it'll do a method call. Just something to be aware of. It's also not just for user-passed values either. The same could apply to random data, or binary data, or the contents of a file, for instance. Watch out if you're doing a YAML parser.
> People fully aware of the XOTcl flexibility have no big problem with this,
> since they can write their own "configure" method (this method
> implements the dash interpretation) and use this (e.g. via mixins)
> where appropriate.
Yes, if something positive has to be said then it is that flexibility. I went one further and already created a method directly into 'Class' ;-)
-- Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/