http://coldfusion.com logo
Join Slack
Powered by
I just finished a job interview, and 2 questions w...
# cfml-beginners
j
I just finished a job interview, and 2 questions were asked that I didn't know about: (1) What is a closure?, and (2) when would you use === in ColdFusion? Is === in ColdFusion similar to when you would use === in javaScript. Can anybody help me understand these two items. Thanks so much!
p
b
Well, the second one is a bit of a trick question as Lucee and Adobe have different 
===
operators!
A closure is generally an anonymous function (UDF), but with lexical scoping.
j
Thanks so much for the link @Patrick Also, thanks so much @bdw429s for explaining things for me. I am going to read the docs for the closure. They did ask if I had experience in Lucee, which I don't.
šŸ‘šŸ» 1
b
i hadn't heard of the === but found this about it. Equality/inequality operator ColdFusion is a loosely typed language, where the engine smartly interprets the type of variable. In ColdFusion (2018, release), ColdFusion preserved the data types, however due to backward compatibility, the equality operator was still comparing two objects by its values and not by types. In ColdFusion (2021 release), we've introduced the operators- Strict equality and Strict inequality, which solve issues related to == or EQ operator. but acting different in lucee is a bit concerning. although i'll side with lucee since i develop on lucee lol i'd be interested in hearing the differences in lucee/acf on this brad šŸ™‚
b
No, Lucee's implementation is dumb
It was done sort of like Java and makes no sense in CFML
Actually I think even Adobe's approach (which is more like JS and what Lucee should have done) is still fairly pointless in a loosely typed language that has an open definition of truthy.
b
interesting
b
I file both engines attempt to add 
===
as "chasing after cool things other languages have". I've never in my 20+ years as a CF dev thought to myself, "Hey, I wonder if this variable is truthy AND is a proper boolean??"
b
i can agree to that statement.
b
I know a lot of JS devs like to write
Copy code
if( setting === true )
and then sit back and admire the great work they've done in the universe that day rooting out imposter settings which were accidentally defined as
Copy code
var setting = "true";
but frankly, I don't see the point. If it's truthy, then it's truthy.
šŸ¤£ 1
b
the company i work for is all over the place for "truthy" statments. 1,true, "yes". heck, even -1 in some instances
b
Yep, I embrace that. It's part of the language and it's a great feature IMO.
i.e.
Copy code
if( myQry.recordCount ) {}
instead of
Copy code
if( myQry.recordCount > 0 ) {}
etc
In a language where
Copy code
sum = "3" + "5";
is totally legit, I don't see the point of
Copy code
if( age === 35 )
when
Copy code
if( age == 35 )
will do just fine. If the age variable somehow came in as a string (which would still pass a 
numeric
check in the function arguments), who cares?
b
i agree with ya
b
Or more specifically-- I've never found a situation where I specifically wanted to prevent accidentally matching a number to a string where the string may have contained a number inside of it. That's just not a requirement I've ever had.
b
maybe they're just flexing to keep up with the "cool kids"
šŸ˜Ž 1
j
Yeah, but have you ever heard of 
====
?
b
Yeah, that one checks the Git blame to ensure the same developer committed the code that defines both variables
šŸ˜† 2
Very important when you want to ensure both sides of the equality check came from the same human eye roll
I'm trying to find the Lucee source code to confirm, but I'm fairly sure the Lucee version does an identity check where it compares the hashcodes of each object.
The funny thing about that is Lucee itself doesn't bother to ensure hashcodes even freaking work right in all of its native CFML datatypes šŸ˜•
Ahh yes, here's the Lucee source code for what happens when you use 
===
in Lucee
Copy code
public static boolean eeq(Object left, Object right) throws PageException {
		return left == right;
	}
It uses the actual Java 
==
check on the objects
b
interesting
b
ok, so no hashcode check. Java does this
The == operator can be used to check if two object references point to the same object.
I remember now-- because that's even more feaking useless of a behavior
Especially considering how Lucee's compiler will optimize immutable variables behind the scenes by re-using the same instance for two different CFML variables.
Anyway, you shouldn't have gotten me started. This is a sore spot for me, and it has been long before I put that ticket in back in 2017
b
Haha. Sorry. Iā€™m enjoying it none the less.
b
Micha and Igal always told me they couldn't change it for "backwards compat" and they are also the only two CF Lucee devs I've seen who EVER used 
===
on purpose
(many people used it on accident over the years, much to their chagrin)
b
well, i can say i learned something new today. === and chagrin šŸ˜‚
šŸ˜‰ 1
yup, i had to google it
a
@bdw429s looks like js devs coming from cfml world
Looks like the closure question is that typical js interview question that has been ported to the cfml interview. A lot of interviewers also don't know what a closure really is, they just say: "it's a function in a function", but the real point is that the inner function preserves data of the outside function mainly because of lexical scoping. When debugging js you'll even see those vars console-logged named as "closures". I guess those question were JS questions taken from somewhere and just thrown into that interview.
In cfml docs you'll often see an attribute typed as "closure" to be used as an inner function.
b
a function in a function
And that's not even a correct answer, lol. Imagine this code index.cfm
Copy code
<cfset foo = ()=>{}>
Where's the "outer" function?
šŸ‘ 1
šŸ˜„ 1
A better question would be, "what's a higher order function", or just "what is functional programming".
b
That hurts my head just looking at it.
3 Views
Open in Slack
PreviousNext
Powered by