CFIF Bug

[john Matlock]

Running the following:

This is a test of CFIF in Railo Version 4.2.2.004.<br><br><!---  --->

<cfset A = 4>
<cfoutput>A = #A#</cfoutput><br>

<cfif A = 11>
    <!--- Yes, I know that the cfif should say "A IS 11", rather than using an equal sign.
    But when some fool uses an "=" rather than an "IS" Railo should throw a diagnostic
    rather than treating it as if it is a cfset.  This makes it hard to debug as to why "A"
    suddenly changed in value. PS. I spent too many years working in other languages
    where you use an =. --->

    <cfset B = 2 * A>
</cfif>

<cfoutput>A = #A#; B=#B#</cfoutput>


Produces:

This is a test of CFIF in Railo Version 4.2.2.004.

A = 4
A = 11; B=22

[Matt Quackenbush]

That's not a bug. You assigned A = 11. You did *not* do an equality check. Change your code to the following:

<cfif A == 11>

--
Did you find this reply useful? Help the Railo community and add it to the Railo Server wiki at https://github.com/getrailo/railo/wiki
---
You received this message because you are subscribed to the Google Groups "Railo" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/railo/dda1a415-c6c0-4db5-9052-0921bffd99e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Adam Cameron]

On Tuesday, 23 December 2014 21:12:43 UTC, QuackFuzed wrote:

That's not a bug. You assigned A = 11. You did *not* do an equality check. Change your code to the following:

<cfif A == 11>

Indeed. An assignment is just an expression. One that returns the value being assigned. And in the example that's "11", which is a boolean true in CFML.

Try this:

<cfoutput>#a=11#</cfoutput>

Outputs 11.

Some languages prohibit assignments in flow control statements, but not all do. So it's not correct to decide this is a BUG, unless Micha didn't intend it to be that way.

-- 

Adam 

[Jeroen Knoef]

Try this:

arr = [a=1]

dump(arr) // outputs [1]

dump(a) // error

It's a silly example, nevertheless, should this then be considered a bug? :-)

What's funny, this works:

s = {x = a = 1}

dump(s) // {x: 1}

dump(a) // 1

[Adam Cameron]

On Wednesday, 24 December 2014 10:08:37 UTC, Jeroen Knoef wrote:

Try this:

arr = [a=1]

dump(arr) // outputs [1]

dump(a) // error

It's a silly example, nevertheless, should this then be considered a bug? :-)

Well... yeah, I guess it is!

As an expectation benchmark, in JS if one does this:
a = [i=42]

One ends up with two variables set:

a = [42]

i = 42

So that'd be how I'd expect Railo to work as well, perhaps. Unless there's a reason for it not to.

Dire bloody code though, eh?

-- 

Adam

[Michael Offner]

to be fair all of this is not working in ACF, ACF does not handle a assignment operation as a expression, like it does for every other operation.

so this works in ACF

a=1+2-1*5/10;

but this does not

a=b=1+2-1*5/10;

it seems that a assignment operation is handled like a statement...

BUT this makes that not a bug in Railo, it is simply a limitation in ACF...

languages like Java, Javascript,php,c[++|#],swift,... acts exact the same way, 

the only language comes to my mind that use "=" for equality comparison is Pascal.

Micha

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/CAKa5oqLvhegitH-semVK__E%3DyUKoXTEhHFuHX56RDr_EMpgRUA%40mail.gmail.com.

[Adam Cameron]

On Wednesday, 24 December 2014 13:36:17 UTC, Michael Offner wrote:

to be fair all of this is not working in ACF, ACF does not handle a assignment operation as a expression, like it does for every other operation.

so this works in ACF

a=1+2-1*5/10;

but this does not

a=b=1+2-1*5/10;

Yeah it does. Multiple assignments are fine. It's just one cannot make an assignment in a statement expecting a conditional expression. I think this is *specifically* done to avoid accidental assignment (=) when a comparison (==) was intended. This is not an uncommmon parsing consideration, in my experience.

 

BUT this makes that not a bug in Railo, it is simply a limitation in ACF...

It could be a compat bug, because you didn't notice / weren't aware of the "cannot assign in a conditional statement" practice. Indeed I'd say it is a compat bug because you were clearly unaware of it, and didn't make the active decision to not follow it.

 

languages like Java, Javascript,php,c[++|#],swift,... acts exact the same way, 

the only language comes to my mind that use "=" for equality comparison is Pascal.

I think you're missing the point. The original issue was an *accidental* use of  "=" as a comparison, and why that didn't cause a parsing error. No-one is suggesting "=" should work as an equality comparsion operator.

The issue is that Railo's CFML implementation allows *assignments* in a conditional statement, therefore the results were "unexpected". They were unexpected because *ColdFusion* does not allow assignments in a conditional, so that is the base-line expectation.

It's entirely reasonable for assignments in conditionals to be either allowed or disallowed: different languages have different rules. However I'm not sure having different behaviour at this level within different implementations of the same language is really that ideal.

So back to what I said... if it was an active decision to conflict with ColdFusion here, by all means offer the explanation, document it, and we can move on. However now having given it more thought, it seems like a bug in Railo's implementation here.

?

-- 

Adam

[Michael Offner]

ACF has not a implementation that has a smart master plan behind it, it is simply buggy, maybe the tried to improve it, but could only do it halway.

Take this examples in ACF:

a=b=1; // works

a=(b=1); // fails!

This is even better:

function test(){return a=1;}// fails

Writedump(test());

What is your logical explanation, that this is not supported? :-)

The acf implementation does not only not work within if/while, it fails in nearly every situation.

Simply looks like a bad patch to a not existing feature...

Micha

--
Did you find this reply useful? Help the Railo community and add it to the Railo Server wiki at https://github.com/getrailo/railo/wiki
---
You received this message because you are subscribed to the Google Groups "Railo" group.

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/d5c5d3a1-0a42-4119-9857-f285cc27ec11%40googlegroups.com.

[john Matlock]

Sorry, that's COBOL not COBAL -- My typing.

Which is how I got into this equal sign business in the first place.

John

On Sunday, December 28, 2014 10:43:22 AM UTC-8, john Matlock wrote:

You guys own the program, I'm just a user.  So, you can do with it what you wish.

This does however mean that Railo is not compatible with Coldfusion, which I consider a bug.  Coldfusion puts out a diagnostic that says something like "Did you really mean to use an "=" or did you mean to use "EQ" or "IS"?

That's a lot more helpful in debugging than suddenly finding that your variable has changed in value, when you didn't know what Railo does. 

For what it's worth, a few minutes on Google regarding using "=" in an "IF" statement turned up several languages besides Pascal that allow it to be an equality operator: Algol, BASIC, Visual BASIC, APT, COBAL and FORTRAN -- at least in some versions, all of which I have used at some time in the past.  In CFML the equal sign is also used in the "cfcase," "cfloop" statement.

John

[Adam Cameron]

This does however mean that Railo is not compatible with Coldfusion, which I consider a bug.  Coldfusion puts out a diagnostic that says something like "Did you really mean to use an "=" or did you mean to use "EQ" or "IS"?

That's a lot more helpful in debugging than suddenly finding that your variable has changed in value, when you didn't know what Railo does. 

For what it's worth, a few minutes on Google regarding using "=" in an "IF" statement turned up several languages besides Pascal that allow it to be an equality operator: Algol, BASIC, Visual BASIC, APT, COBAL and FORTRAN -- at least in some versions, all of which I have used at some time in the past.  In CFML the equal sign is also used in the "cfcase," "cfloop" statement.

I had a look at this on my blog over the break: http://blog.adamcameron.me/2014/12/cfml-assignments-in-conditional.html (and checking some somewhat more contemporary languages ;-)

On reflection - and feedback I've got - being able to have an assignment statement in a conditional expression is undesirable.

So Railo is a) contrary to CF; b) not indicating desirable behaviour.

I'm going with "Railo bug" (the bug being bad - even if intentional - language design, in this case).

-- 

Adam

[Jesse Shaffer]

I agree with this assessment.  Take the following code example of how it could be useful (I've seen similar examples in JS applications):

var value = "";
var xmlString = "";

xmlString &= "<users>");
for (var userRow in userQuery) {
   xmlString &= "<user>";
   for (var column in userRow) {
      // assign the field value to a holder variable to output below, and for whatever reason, ignore empty columns.
      if ((value=userRow[column]) != "") {
         xmlString &= "<#column#><![CDATA[#value#]]></#column#>";
      }
   }
   xmlString &= "</user>";
}
xmlString &= "</user>";

I would not consider it a bug on either side though, just implementation difference that probably should be documented on Railo's side.

[Adam Cameron]

On Tuesday, 30 December 2014 16:55:56 UTC, Jesse Shaffer wrote:

I agree with this assessment.  Take the following code example of how it could be useful (I've seen similar examples in JS applications):

      if ((value=userRow[column]) != "") {

That's a slightly different situation: there's an assignment in the conditional statement, but it's not the entirety of the condition expression (if that makes sense).

I'd be completely fine with that sort of thing, as it's not really ambiguous as to whether it's by design, or justa typo, like this would be:

      if (value=userRow[column]) {




-- 

Adam

 

[Jesse Shaffer]

I see what you're saying, but I'm not sure how that line could be drawn realistically:

I see three possible options:

a) wholly (dis)allow assignments - split decision it seems

b) allow assignment, as long as there is at least one other operator (one could get confused with if (n = x % 2) vs if (n == x % 2) because improper variable names were used), or

c) allow assignment as long as it is used in conjunction with a logical operator  ( if ((remain=x%2) > 0), but then > 0 is extraneous in this instance, as proper variable names were used to show intent)

My initial reaction is to go with wholly allowing them, as it is the implementation javascript has taken.  I would think it more likely that someone working with CFML would be using it in conjunction with JS.  Seeing as this behavior seems to be accepted and understood in the JS community, I don't see a problem with it in CFML.

In fact, I generally would prefer sticking to ECMAScript standards when possible in determining behavior such as this, unless there is a real need to do otherwise.

[john Matlock]

Two comments:

1. It seems that you guys are thinking about how you write programs to do something, and that you don't have a few hundred templates or pages written in the last half dozen versions of Coldfusion. If you make changes in the interpreter that affect older programs you create a horrendous task of going back to be sure the old stuff works.

2. This particular change probably shouldn't hurt the old programs because if they are working they should all have "EQ" or "IS" in the "cfif's."  But if this is just the start of changes to be made in the language just because somebody thinks it's neat, then Railo will get further and further away from Coldfusion so that getting CFML people to move to Railo from ACF will get more and more difficult.  Railo will become a smaller and smaller offshoot of Coldfusion which is already becoming a small offshoot of the web development world.

For what it's worth, my opinion is to keep the base language compatible with ACF. If you want to make extensions to expand the capabilities fine, but make it something different  rather than changing the behavior of an ACF tag.  Forcing you to add multiple operators is one way.  Another, and I think easier to explain to a newbie would be to change the command, i.e. <cfif> works just as in ACF, <cfifx> for extended functions.

[Jeroen Knoef]

There are a few other instances where Railo does things differently from ACF. One example is that arrays are passed by reference whereas ACF copies the array first. I’m not hoping that this deviation from ACF is going to be ‘corrected’. As long as a (hopefully simple) workaround exists I’m not against features like this, and certainly wouldn’t consider this a bug.

BTW I suspect that this is not a recent change, but something that’s been in Railo from the beginning.

[Nando Breiter]

John,

I wouldn't blow this out of proportion. There are, inevitably, differences, and neither ACF or Railo are without bugs. I'm the process of porting several apps from ACF9 to Railo, and one from ACF9 to ACF11 (for now). The incompatibilities between ACF9 and ACF11, and the frustrations I encountered on the way, bothered me more than those I'm finding between ACF9 and Railo 4.2. The reason is that it seems to me the ACF engineers have been careless in the way they unnecessarily introduced bugs that weren't there before. And haven't fixed bugs that have been in the codebase for ages.

On the other hand, it is my impression that the Railo team, with much more limited resources, is doing a better job at maintaining a reliable CFML engine, and from what I understand of Gert's preso on Railo 5, is headed even more in this direction. It may be different. I may need to use the search and replace function in my editor to change a few hundred files, once I get to the root of an incompatibility. That's fine. What matters more to me is reliability, rather than slavish compatibility to ACF, because that's what my clients care about. 

What I realized along the way in the process is that all along, I've adapted my code to ACF's quirks, failings, and way of doing things (rather than to Railo's). That's just how programming is. The fact that I need to make a few adjustments to my codebase (and perhaps file a few bug reports) when changing engines is perfectly understandable. 

Here's my shortlist so far:

In Railo, getPageContext().include() isn't working the same as it does in ACF. I decided to work around this by using getPageContext().forward() instead, for now, which works in both engines. getPageContext() is an undocumented feature. I'm not sure if it is fair that I even expect this to work. 

In Railo, I have trouble maintaining the varchar type on a QofQ for a value that sometimes looks like a decimal: 43.2, and sometimes does not: 43.home. The where clause then incorrectly selects 43.2, 43.20 and 43.200 as equivalent. I worked around it by introducing another field in the query without a decimal point. I think this should be reported as a bug, but I have yet to research it carefully. 

In Railo, a mix of date types and timestamp types are not sorted in date order as I would need them to display a schedule of events (that could be date-based alone, or datetime range based). I'm working around this by changing the date type to a timestamp with a time value of 00:00:00.

In Railo, when generating PDF's using cfdocument, you need to add a div surrounding all other tags that sets the size of the page to get it to render correctly.

... and a sample of the other way around ...

In ACF9, 10, and 11, the ORM setting dbcreate="update" is broken on a particular app I'm developing, and has been for some time. The underlying SQL fails to generate a constraint properly, and takes the whole application down with it. I don't have a viable workaround, except not to use it, which is a PITA. I can't detect any sensible pattern to this bug. For instance, adding the entity "Invoice" broke the app. If I changed the name to Innvoice, it worked. I couldn't swallow such an inane workaround, so the entity remains named "Invoice". 

dbcreate="update" works without a hitch on Railo, on the exact same code and database. So perhaps the workaround is to use Railo instead. 

On ACF11, I've had repeated difficulty using the admin panel. I get automatically logged out whenever I try to make a change, like adding a datasource, or adjusting any other setting, and redirected to a screen inviting me to log back in again. The logs show a message "Unauthorized access suspected". The workaround is to clear the browser cookies (which I only hit upon after an embarrassingly long amount of time and frustration), which again is a PITA. I suspect that the ACF team decided to block attempts to administer more than one instance of ACF as a "security feature", but I haven't gotten to the bottom of this yet. No such trouble logging in and using the Railo admin panel.

On ACF11 pre-update3, I could not log into any of my applications. It seemed the session scoped variables that my code set on login simply didn't work. I was not at all pleased that I couldn't even test my apps on ACF11 without disabling the login mechanisms. On Railo 4.2, I have no trouble logging into my apps.

A further frustration with ACF11 is that although I pay for support, it is very difficult to reach them, and what I get back if I do has been woefully amatuer. Adobe makes every effort to keep you as a paying customer, but it seems to end there. If I'm using Railo as part of my business, I'd rather be paying Railo a base yearly support fee, just for the updates they already provide.

Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

--

Did you find this reply useful? Help the Railo community and add it to the Railo Server wiki at https://github.com/getrailo/railo/wiki
---
You received this message because you are subscribed to the Google Groups "Railo" group.

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/8a814561-8a6d-4caa-8bf9-1af787a3d2d2%40googlegroups.com.

[Terry Whitney]

Adobe ColdFusion version jumps have always been problematic at best. Even the same code that ran perfectly 7 would break on 8 or 9, and the whole jump to 10 & 11 only caused further code "fixes" to code that previously worked flawlessly on a prior version. 

The problem with Adobe ColdFusion is you pay thousands of dollars to acquire enterprise level functionality, then you pay thousands more for support only to have someone with less than a basic understanding of ColdFusion tell you, oh well send us your entire code base and We will blame your code. 

I would happen to agree with Nando, I would rather see a support contracts go to Ralio over Adobe as much as I love to see Adobe continue to produce great products, I feel as though ColdFusion is one product they never fully have marketed and in the case of 11, rushed to market without having most of the features working correctly on all platforms.

I would have to say that Ralio, while it may have some bugs here and there, for the most part is rock solid, has a far less resource imprint than Adobe ColdFusion and is fast as hell.

[Michael Offner]

Fyi Railo work that way since version 1, Railo is more compatible to acf today than in was in version 1.

So no idea from where you get the idea that Railo is going further away from acf.

Like you can see in my examples before, acf has a terrible handling of the assignment operator, something for sure not worth following! Railo handles this operator like defined with ecma script (http://www.ecma-international.org/ecma-262/5.1/#sec-11.13), remember acf cfscript is by definition ecma script compatible.

About newbies, most newbies are familiar with JavaScript that works exact the same way...

Micha

--

Did you find this reply useful? Help the Railo community and add it to the Railo Server wiki at https://github.com/getrailo/railo/wiki
---
You received this message because you are subscribed to the Google Groups "Railo" group.

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/8a814561-8a6d-4caa-8bf9-1af787a3d2d2%40googlegroups.com.

[Michael Offner]

I was strongly against following acf here, as far as I know acf has handled arrays as string list internally in the first versions, acf acts still this way to be compatible to this versions. But following acf in that case was never a option for us! 

BUT we added the attribute "passby" to the tag "cfargument" so you can make a single argument compatible with acf, of course you can also use the function duplicate, what is by far the better solution. 

Even php has changed from "by value" to "by reference" in version 5 for all types passed to functions,  what has broken existing apps, but it was still worth doing. Because pass by value sucks in 99.999% of the cases! Compatibility to acf is still extremely important to us, but not for every price, if compatibility mean to have a implementation that is bad for 99.9% of the users...

Micha

Am Dienstag, 30. Dezember 2014 schrieb Jeroen Knoef :

There are a few other instances where Railo does things differently from ACF. One example is that arrays are passed by reference whereas ACF copies the array first. I’m not hoping that this deviation from ACF is going to be ‘corrected’. As long as a (hopefully simple) workaround exists I’m not against features like this, and certainly wouldn’t consider this a bug.

BTW I suspect that this is not a recent change, but something that’s been in Railo from the beginning.

--
Did you find this reply useful?  Help the Railo community and add it to the Railo Server wiki at https://github.com/getrailo/railo/wiki
---
You received this message because you are subscribed to the Google Groups "Railo" group.

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/B8A99E58-4CDD-4A79-A02E-FDD256CA7746%40neoneo.nl.

[Adam Cameron]

On Wednesday, 31 December 2014 14:01:13 UTC, Michael Offner wrote:

remember acf cfscript is by definition ecma script compatible.

Um... no it isn't. At all. There is no specific attempt to follow the ECMAScript standard. And it's very woolly-headed of you to think that it is.

Just like not all languages that use angle brackets are XML (nor ought to be, nor ought to make attempts to be written that way), not all language syntaxes that use curly braces etc are intrinsically making any attempt to follow the ECMAScript standard.

That said, there is no reason to not mimic the ECMAScript standard in situations where all other things are equal, and it makes sense in the context of CFScript's existing implementation, but CFScript is - in no way - related to ECMAScript. Nor does it need to be.

Whilst researching this, I came across something interesting - and in context of the origins of this thread: https://wikidocs.adobe.com/wiki/display/coldfusionen/The+CFScript+language#TheCFScriptlanguage-DifferencesfromJavaScript

"Assignments are statements, not expressions, and therefore cannot be used in situations that require evaluating the assignment operation."

So assignments very specifically are not supposed to be expressions. This is codified in the closest thing Adobe has to a specification for CFScript (which the docs are).

In that light, I'm calling this a compat bug in Railo. That's not to say I think you should address it, but that's what it is. I do not think it's very clever of Railo to diverge from ColdFusion here though, TBH.

-- 

Adam

[Denny]

On 01/01/2015 06:25 AM, Adam Cameron wrote:
>
> On Wednesday, 31 December 2014 14:01:13 UTC, Michael Offner wrote:
>>
>> remember acf cfscript is by definition ecma script compatible.
>>
>
> Um... no it isn't. At all. There is no specific attempt to follow the
> ECMAScript standard. And it's very woolly-headed of you to think that it is.
>
> Just like not all languages that use angle brackets are XML (nor ought to
> be, nor ought to make attempts to be written that way), not all language
> syntaxes that use curly braces etc are intrinsically making any attempt to
> follow the ECMAScript standard.

I love your certainty! I rarely manage to pull off that level of
self-assurance. (I blame Socrates.) =)

Even though CFML tags aren't XML, I like to add closing /'s and whatnot,
mostly because visually it helps. Are you saying it actually hurts?
Should spaces (or tabs-- game on!) be enough? :)

ActionScript is ECMAScript, I reckon, but it isn't JavaScript, neh?

I'm not saying Micha didn't miss a "not" in there, but it is a
possibility... or maybe it isn't. I'm not certain, but I'd lean towards
it, if I interpreted the surrounding sentences correctly.

Apropos to nothing, I wish I spoke Spanish as well as he speaks English
(or even typed it as well). And that's the only other language I even
half-ass kinda know, beyond the computer ones! I've got a lot of
respect for the man. (For everybody, really. Probably Plato's fault.)

> That said, there is no reason to not mimic the ECMAScript standard in
> situations where all other things are equal, and it makes sense in the
> context of CFScript's existing implementation, but CFScript is - in no way
> - related to ECMAScript. Nor does it need to be.

Meh. I'd prefer if it was I think. Remember this?

http://forta.com/blog/index.cfm/2011/2/4/I-Am-Not-A-Fan-Of-CFSCRIPT

FWIW, I'm not saying you're wrong, per se, just that as someone who
writes lexers and parsers for CFML, it would be kinda neat if the
"script" bits were ECMAScript compatible. The problem is mostly the one
outlined by Ben-- "evolution", if you will. It's a pretty common
problem, FWIW, and a recurring discussion on the list.

:Den

--
"...which is, of course, what this is all about.
Compatibility, Morpheus, Compatibility..."

[Michael Offner]

What I said! Assignment operations in acf are statements and not expressions. You write acf is very strict on that, why is then this supported?

A=b=1;

You said it is working everywhere as expression except inside "if/while" and i proofed that this is not the case ... (A=(b=1);)

You can not have everything ;-)

Please explain me again the logic in acf, if you can I will accept  it as a bug ;-) but remember the code examples I did that do not work in acf

Micha

--

Did you find this reply useful? Help the Railo community and add it to the Railo Server wiki at https://github.com/getrailo/railo/wiki
---
You received this message because you are subscribed to the Google Groups "Railo" group.

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/27569bce-5b00-4859-beff-21c4753623b3%40googlegroups.com.

[Ed @ ODI Consulting]

This is not a bug; but, I can see where it could cause difficulties.

Personally, one of the things I've always wanted CF to have is the ability to quickly initialize a bunch of variables like: var a=b=c=0;  Now, in Railo that's there.  On the other hand, I see the point; that, for by way of example, for vb coders normally would use if a=b then c=d, and are expected to switch to <cfif a is b><cfset c=d></cfif>, the new java style assignment could create hard to diagnose results.
To ease debugging, by default, I think the following x=y(s) should generate "Assignment not allowed there" errors: <CFIF x=y>, if(x=y), for(i=1;x=y;i++); j=(x=y)?4:5;while(x=y), iif(x=y,4,5).

ps: in var a=b=c=0; I've not tried this yet; but, I would hope that a, b and c would be scoped to the enclosing method (and not just a).  Can anyone confirm that assumption?