On Nov 29, 2007, at 8:10 AM, Stephen Deasey wrote:
> On Nov 29, 2007 6:45 AM, Vasiljevic Zoran <[EMAIL PROTECTED]> wrote:
>>
>> On Nov 29, 2007, at 7:32 AM, Stephen Deasey wrote:
>>
>>>
>>> Are you saying that "false" is not false and "true" is not true?
>>
>> I'm saying that false IS zero and 1 IS true (better, non-zero is
>> true).
>
>
> OK. But why are you saying that?
Because you asked:
"Are you saying that "false" is not false and "true" is not true?"
so I wanted to make clear what I'm saying.
>
>
> The Tcl man pages define explicitly what the valid values for boolean
> are, and in what context booleans are expected. Can you point to the
> part which supports your argument?
>
I cannot, because Tcl has no strict typing. All this is really
best-effort where possible. This is not something that the
language enforces. You can't (nobody can) make Tcl typed language
as if you want to do that, you will break the backward compat
and in this particular case, you would defeat the whole purpose
of the language.
>
>> But this can bring us to the question:
>>
>> set value [ns_config -bool jummy juice false]
>> if {$value == "true"} {
>> # ...
>> }
>>
>> and all sorts of other weird things. I know I know...
>
>
> This is a false dilemma.
>
> A string equality expression is not the only substitute for an integer
> comparison expression.
>
> if {$boolilicious} { ;# <--- boolean expression
> puts "truthy"
> }
>
In the IDEAL world, we would have Tcl types. But then again,
why bother with Tcl and don't use Java or C## or something
"typed"?
>
>> This all ISN'T very clear because Tcl's C-heritage and
>> LACK of proper boolean type (actually lack of ANY types).
>
>
> Tcl has a boolean type:
>
> http://www.tcl.tk/man/tcl8.5/TclLib/BoolObj.htm
>
> It's string rep when false is 0, false, no, f and so on.
>
This is only a boolean type if you want to treat it as boolean.
Otherwise it is just a string.
>
>> So, we cannot teach Tcl types, we can only make some
>> approximations. The (ns_config )code was simply too strict
>> at that place
>
>
> It was returning a boolean value, guaranteed.
It did, yes. But it did not follow the assumption that people
would test the return value with numeric comparison relying
on the fact that zero IS true. And this is what you are
accustomed when comming for C. Nobody in C would write
char *false = "false"
if (false) {
}
and everybody is simply accustomed to zero/nonzero integer
value to hold for false/true. This is also valid for Tcl.
Just about lately they (Tcl) started to mingle with true/false
in expressions and that created all this mess. We cannot
fix that mess. But I'm also not going to change my scripts
because of that mess.
But hold on... why are we consuming list bandwidth
on this obvious thing? It is simple as that: the code was
not broken essentialy. It was simply too "straight" and
broke backward compatibility w/o any good reason.
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
