The original question is whether this behaviour in CF is buggy.  It seems we
do agree that the behaviour is NOT buggy.  I for one am perfectly content to
only supply boolean expressions where boolean expressions are required,
thereby eliminating the issue.  You'd never see code like you proposed in an
app I wrote.  You'd see this instead (which isn't symptomatic):

> var a = true;
> var b = 20;
> alert((a && b != 0) == );
> if ((a && b != 0) == (b != 0 && a)) alert(true);
> else alert(false);

Yes, I'm explicitly not doing what the language designers allow me to do,
but I do the same thing by scoping variables, and a myriad of other things.

Whether the designers of CF (and JS, VBS, etc) were smoking of the crack
when they designed the languages is another debate that I'm not going to get
into.  Suffice to say that if you know and understand the language you're
using, you can avoid any such pitfals and usually benefit from the
advantages that the compromise the language designers made allowed.

Cheers,
barneyb

> -----Original Message-----
> From: Claude Schneegans [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 21, 2004 11:19 AM
> To: CF-Talk
> Subject: Re: Is it a bug or not a bug?
>
> >>You're still missing the fundemental point about a loosely
> typed language.
>
> I'm not missing anything. This has nothing to do with lousely or not.
> Lousely typed does not mean the type does not exist, what it
> means is that the variable will be converted during execution
> to a type suitable according to the operators in expressions.
> Loosely or not loosely, types do exist.
>
> I agree that in _javascript_ (true && 20) returns 20, like CF,
> you get a point here.
> Now if this is not a bug, this is a severe design flaw.
>
> Take this for instance:
> var a = true;
> var b = 20;
> alert((a && b) == );
> if ((a && b) == (b && a)) alert(true);
> else alert(false);
>
> This outputs false in both cases.
> Now, every body knows that a logical AND is a COMMUTATIVE operation.
> Then (a && b) should ALWAYS be the same as (b && a), for any
> values of a and b.
> A "language" that does respect this is not really a language.
>
> The same _expression_ in C returns true whatever integer values
> are given to variables, even with shortcuts in evaluation.
> This is fundamental.
>
> So, my conclusion is that CF, perl, _javascript_ are not just
> loosely, the are also lousy. ;-)
> --
> _______________________________________
> See some cool custom tags here:
> http://www.contentbox.com/claude/customtags/tagstore.cfm
> Please send any spam to this address: [EMAIL PROTECTED]
> Thanks.
>
>
>
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]

Reply via email to