http://coldfusion.com logo
Join SlackCommunities
Powered by
I know Lucee struggles with optional semi-colons, ...
# lucee
a
I know Lucee struggles with optional semi-colons, but wondering if this is a known one:
Copy code
<cfscript>
cfhttp(method="get", url="<https://example.com>", result="httpResponse")
</cfscript>
Copy code
Syntax Error, Invalid Construct
Obvs there is not a syntax error in that. And it works fine in CF. I could not find a bug in Jira that covers anything like this, but I'm certain it's been raised before. (and before anyone starts, yes I know there are other Lucee-only constructs to achieve the same ends. This is not relevant here. It's that code that should work).
b
I've noticed that before and I think a ticket is in order. Lucee requires the semi there but clearly it shouldn't be necessary given the parens (and so long as the next non-whitespace char isn't a 
{
✅ 1
a
I guess even if I raise one and it turns out to be a duplicate, someone can just close it.
I think the testing of this feature could do with some strengthening too. This is is not an edge-case.
👍 1
b
Yeah, I'd file it under compat and maybe do a quick test of some other ACF tag-in-script examples
a
Ah. They can test their code: they're the ones who know how their code parser works, and what testing considerations they've omitted. I'd say there's fewer than a dozen variations they need to think about. Just requires sitting down and thinking through what they are, write tests, put that up for code review so more eyes get on it, and then fix the implementation to pass the tests. I've brought it to their attn. Ball's in their court now.
b
That's not quite what I meant. If you put in a ticket that says "this specific tag doesn't work", sometimes you'll have people JUST fix that tag and nothing else. But if you say "The ACF-style tag-in-script syntax requires a semi-colon in all cases when it shouldn't" it's a bit more clear
That said, it's Adobe who usually suffer from that, Lucee is much better about thinking systematically about the fixes.
Usually 😆
a
10yrs ago I would agree with you. I've found a disappointing amount of flakiness in Lucee recently, cf CF2021
I mean I dev in Lucee daily so more Lucee CFML passes over my desk, but any idiosyncracy I find I test on CF and CF usually has it nailed. But I guess that's confirmation bias in a way. It's surfacing things wrong in Lucee and there's no reason to think CF would have the same thing wrong. If I was doing CF daily, the situation might be reversed I guess.
For my after-hours work I write it all to run on both. And I think CF2021's CFML is a bit ahead of Lucee's ATM. There's a bunch of stuff in CF2021 that Lucee hasn't caught up with yet. Not a recrimination: just an observation. Different budgets / personnel levels etc. I understand that. However it is what it is.
Sorry missed this bit:
That's not quite what I meant. If you put in a ticket that says "this specific tag doesn't work", [etc]
I do think my observation about the testing kinda alludes to that situation. Although I'm not explicit about it. Sigh. All right... I'll update...
That said... I don't think this is anything to do with 
cfhttp
. It's all down to how they interpret the end of a statement. And in the case of the 
cfwhatevertag
implementation, they've not nailed it. Poss down to the ones that can optionally take a block. Again... dunno... I dunno how they've implemented this. But they do.
m
I think without ; would work if you add { }
a
Apparently, @bdw429s even though i went to lengths in the ticket to explain how just testing this one case was not sufficient... that's exactly what they went and did: https://github.com/lucee/Lucee/pull/1643/files
🤭 1
5 Views
Open in Slack
PreviousNext
Powered by