tracker issue : CF-3910529

really a bad one to break - I dont understand how there isnt a very simple unit test for this? +1

Vote by External U.

Can we pls get a sit. rep. on the fix for this? It needs hotfixing ASAP.

Comment by External U.

Where's the hotfix? Let's go! This needs to be fixed immediately.

Vote by External U.

Bugs happen. And I'm glad you've verified and marked this one as to-fix... but this delay is horrible. What's going on? You could at least have the decency to give us an estimate on when the fix will be available... Meanwhile code I've been writing is now broken because you broke it, and some of the other bug-fixes in CF11u3 are important to me, so downgrading to u2 isn't an option in production.

Comment by External U.

+1 - This needs a hotfix ASAP!

Vote by External U.

Where's the patch for this, Adobe?

Comment by External U.

This bug is fixed and targeted to be provided publicly in Updater 4 for ColdFusion 11 on regular quarterly patch schedule. If you need a fix sooner, please contact our support team to request a private fix for this.

Comment by Elishia D.

I've already stated this elsewhere but just to put it on the record: I think that waiting for a quarterly update to fix a regression Adobe caused is terrible. You say, "If you need a fix sooner, please contact our support team to request a private fix for this." This implies that you have or can fairly easily create an update that fixes the issue. Why not just release that as update 4 and push all of the other non-update3-regressions back to update 5 on its normal schedule? Further, "If you need a fix" can be rewritten as, "If you're using this feature" and I can assure you that either people have rolled back to update 2 or removed the feature from their code, because having syntax errors in your code is not just something you can leave be while you wait 3 months for a fix. Either one is a losing proposition: There were things that are very nice to have included in Update 3 (many, many things, if my memory is correct. And if so, good and thank you for the update!) so rolling back to Update 2 denies us of useful features and bug fixes JUST like staying on Update 3 would deny us of this feature.

Comment by External U.

+1 - recommend a hot fix before the quarter

Vote by External U.

Please explain in 25 characters or more how this bug impacts productivity and why you are adding a vote

Vote by External U.

This might be a good time to fire up the pre-release update channel again. Don't be afraid to push out several pre-release updates for every production one. It sounds like you'll have several people waiting to test the fix.

Comment by External U.

What is the point of adding an automated update system - with so much fanfare - if you're not going to release bug fixes throughout the year via that channel? A lot of people were excited that you finally followed Railo's lead by adding the updater system but this response to Adam Tuttle just makes a joke of it. Railo release new patches regularly on a dev channel, often with just one or two bug fixes in each patch. That's what you should be doing too.

Comment by External U.

You broke it in update 3 and it's still broken in update 4.

Vote by External U.

Sorry Elishia (and I know you're only the mouth piece here, I'm not faulting you personally at all), but that's not good enough. The bug described here was CAUSED by Adobe's recent patch, and accordingly "emergency" remedial action is entirely appropriate to sort it out. You can't specifically break something then go "oh... you know... next round of releases", which is what you're doing here, basically. The Adobe ColdFusion Team has to grow up a bit and take responsibility for their actions. They don't seem to get that we *pay* for ColdFusion. It might just be some job they show up to Mon-Fri, but for your clients CF is a mission-critical app, and deserves to be treated accordingly. You price and sell this thing as an enterprise solution. You need to actually treat it & your clients that way too. U3 broke a fundamental feature of CF11, and was identified accordingly fairly promptly. If you're at all professional, you really ought to get a hotfix *for this specific issue* released ASAP. Otherwise U3 is not a viable for a section of your paying customers. As Sean points out you vaunted your patching mechanism in CF10 and CF11, and have used it to good effect since its release. So I can see no reason why you don't use it in the way it was intended and release a fix for this as soon as you can, so we can all put this behind us. Bottom line... you messed up, you need to actually own that and then sort it out. Cheers.

Comment by External U.

+1 //////////////////////////////////

Vote by External U.

Need this now, not later.

Vote by External U.

A regression fix should be released as soon as it's available, not held back until the next scheduled update release.

Vote by External U.

This is just sad. We have a team that's half-Groovy, and we're all used to the Elvis operator. Finding it suddenly stopped working, and that Adobe's attitude is "we'll fix it eventually...meanwhile, you kids go update your production code, ok?" is a huge turnoff.

Vote by External U.

Upvoted. If you're adding new operators to the language, I'd highly suggest adding a test for them. It's just unprofessional to have something like this break and to not notice it.

Comment by External U.

All, this bug is fixed and available for testing with the latest Updater 4 that was released and blogged here: http://blogs.coldfusion.com/post.cfm/coldfusion-11-update-4-is-available-for-early-access I don't think the external bug view shows that this bug is included in U4, so wanted to communicate that here as well.

Comment by Elishia D.

First off, thank you for releasing a pre-release of the patch today. However, the elvis operator (this bug) is NOT fixed. It works in the simplest of cases: time = now() ?: now(); //=> current time However, when combined with even the simplest of objects, it falls completely flat: foo = { x = function() {} , y = function() { return 'y'; } }; writedump(foo.x()); // undefined writedump(foo.y()); // y writedump(foo.x() ?: foo.y()); // undefined writedump(foo.y() ?: foo.y()); // undefined writedump(foo.x() ?: server.coldfusion.productversion) // prints productversion HOWEVER: If you copy these values into simple variables, then everything works fine: a = foo.x(); b = foo.y(); c = a ?: b; // y d = b ?: b; // y So it looks like your code falls down if the expression being checked contains a [dot], as in foo[dot]x(). Feel free to add these tests to your test suite...

Comment by External U.

Just for this one bug, can we see your unit test coverage for this operator? Maybe if we work together we can come up with comprehensive test coverage and get this thing working once and for all? Why is this ticket closed? The fix is in pre-release - it hasn't shipped yet.

Comment by External U.

can't use it, it's broken.

Vote by External U.

FFS

Comment by External U.

Confirmed what Adam Tuttle already mentioned: this is only partially fixed in CF11 Update 4 (build 11,0,04,293085(PreRelease)). The example in the description works, but his example does not. Since both examples worked in CF11 Final, this ticket should not be closed and CF11 Update 4 should not be released until this issue is fully fixed. Thanks!, -Aaron

Comment by External U.

You need to reopen this bug. It is NOT fixed.

Comment by External U.

Just saw this post about Update 4 (build 11,0,04,293085(PreRelease)) being refreshed: http://blogs.coldfusion.com/post.cfm/coldfusion-11-update-4-pre-release-build-has-been-refreshed This ticket probably should've been updated w/ that same note. Verified Adam Tuttle's example now works in CF11 Update 4 (build 11,0,04,293127(PreRelease)). Thanks!, -Aaron

Comment by External U.

Thanks for the update Aaron (shouldn't the CF team be telling people stuff like that tho'? :)

Comment by External U.

Hi Sean, I totally agree! (to Adobe:) The subscribers to a ticket are likely the most willing to verify a ticket's fix. So, adding a comment on a ticket, w/ a link to the associated blog entry, would be the most direct way to get the fastest feedback on a ticket's fix. Perhaps when updates are released for public beta testing, a note could be added on each affected ticket that has a link to the blog entry about the update. Not everyone checks the blog or CF Admin's updates page on a regular basis. Thanks!, -Aaron

Comment by External U.

please omit the "or CF Admin's updates page" b/c public beta updates aren't currently listed on that page (tho I believe perhaps a ticket has been filed to include public beta updates on that page

Comment by External U.

Thanks Sean and Aaron. @All - The fix for this bug is available in the refreshed update 4 bits. Would appreciate if you could share some early feedback about the fix. The following blog post has more details: http://blogs.coldfusion.com/post.cfm/coldfusion-11-update-4-pre-release-build-has-been-refreshed

Comment by Vamseekrishna N.

You didn't address Ryan's question about the unit testing.

Comment by External U.

Nor have you indicated when (even roughly, if that's all you can say) we can expect this update to be distributed over the stable release channel for our production servers?

Comment by External U.

This issue is NOT fixed - the null coalescing operator is still broken in the released update 4. Given that #CF-3840570 is marked as fixed in update 5 (not tested yet), at least someone at Adobe is aware of this, so why has this issue not been re-opened?

Comment by External U.

Peter: this is not a loaded question at all, just trying to understand. Is this and your other issue actually the same, or representative of two different bugs with ?: If so, could it not be the case that THIS ONE is fixed, and the other is not? Or are they too closely related to be considered different?

Comment by External U.

I don't see a reason to differentiate - the operator should work consistently and as documented in all situations - if it doesn't, it's broken, and neither issue is fixed. (I wouldn't have objected to either one being closed as a duplicate of the other.) I had assumed the examples in mine were the same issue as what Adam Tuttle figured out - that it's due to dot notation - but Aaron Neff says those ones work now, whilst the person who updated to u4 here said they still had problems. (I haven't done the update because I'm in the middle of stuff I need to get done, and don't have sufficient trust in the current update process not screwing things up.)

Comment by External U.

Updater 5 has broken this functionality again -- broken what update 4 (partially) fixed. Are you embarrassed? You should be! This is ludicrous. function getById( id ){ return entityLoadByPk( "Message", id ) ?: entityNew( "Message" ); } ... returns null. A round of applause, please.

Comment by External U.

[clap... clap... clap... [etc]]

Comment by External U.

We have attached a code snippet that is similar to the one reported in this bug. This seems to work fine for us.Let us know if there is anything specific that we are missing.

Comment by Suchika S.

Why didn't you just try the example code Adam (the other one) provided? Why did you write *different* code? Surely as a baseline you first confirm that there is the issue Adam suggests there is, and then move on from there.

Comment by External U.

Well, Adam, they pretty much do the same thing

Comment by Vamseekrishna N.

*Except*, obviously, Adam says his code demonstrates the incorrect behaviour, and your code doesn't. Which is, you know, pretty much the crux of things here. So in this case "*pretty much* the same thing" isn't actually helpful. Is it? Or even if you didn't start with Adam's code, and for some reason thought it sensible to start with different code... once your code didn't demonstrate the issue Adam reported, how is it you didn't discard that as not being a valid test case, and THEN use his example, because clearly there is some difference. How is it you thought that reporting back that different code from the example reported not having the issue wasn't just a basically pointless thing do to? All that aside... simply from a procedural process, how is it your starting position is not *with the code you've been handed that claims there's an issue*. Seriously, can you pls explain why you didn't *start* with Adam's code? What was the thinking there?

Comment by External U.

Have you tried with MySQL instead of Apache Derby? Have you tried using a real Application.cfc instead of some <cfscript> lines inside a file named Application.cfc? Have you tried using a service object instead of a function inline in the view file?

Comment by External U.

Adobe, The documentation for Elvis is incorrect. It reads "In an expression, if the resultant value is not defined, then the object will be assigned to the left most part of the expression...." Elvis is a binary operator. It compares two expressions - it doesn't perform any assignment! (something) ?: (somethingElse) The documentation should read "If the left-side expression evaluates to null, the result of the right side will be returned. Otherwise, the result of the left side is returned."

Comment by External U.

Adobe, Building on my prior comment: your Elvis functionality is inconsistent with other major languages. In other languages, when "?:" is used as the Elvis operator, it functions in a manner that's short for ternary operations. In other words, both of these should display "Right-side of Elvis," but the second displays "false" instead: <cfset testValue = false /> <cfset result = testValue ? testValue : "Right-side of Elvis" /> <cfoutput>#result#</cfoutput><br /> <cfset result = testValue ?: "Right-side of Elvis" /> <cfoutput>#result#</cfoutput><br /> When other languages have used "?:" as Elvis, they've obeyed the "It's short for ternary" rule. Instead of evaluating the left-side for being null, it's evaluated for whether or not it's true. C#, where Elvis is "??": // Will assign "Default Title" to "result" string result = false ?? "Default Title"; Groovy, where Elvis is "?:": // Will assign "Default Title" to "result" String result = false ?: "Default Title' PHP, where Elvis is "?:": // Will assign "Default Title" to "result" $result = false ?: 'Default Title' Basically, in a language where ?: looks like Elvis's hair and eyes, it should be short for ternary, not a null coalescing operator. I'd urge you to correct both your documentation and your misunderstanding of Elvis in general.

Comment by External U.

Joe: "returns the first operand unless it is null, otherwise the second operand"?

Comment by External U.

(sorry, replied before reading your second comment Joe). Yeah, you are - actually - dead right! I had never tested ?: on Groovy etc with false values. Makes me pleased I actually initially requested ?? rather than ?:. Less pleased they didn't pay attn to me.

Comment by External U.

Adam, Yes, '??' would be much more appropriate!

Comment by External U.

And why does bugbase list newest comments first, unlike Jira and every blog commenting system on the planet?

Comment by External U.