ColdFusion has a contains
operator, as in:
if ( value contains "foo" ) { ... }
To be fair, I almost never use this; but, I do like the sematics of it. Seems strange that we don’t have a startswith
and endswith
operator as well. As in:
if ( value endsWith "@bennadel.com" ) { ... }
if ( value startsWith "http://" ) { ... }
I know that the underlying java.lang.String
implementation has these corresponding methods. So, it seems like it would be rather trivial to expose them as operators ?
3 Likes
You already can…
<cfscript>
foo = "Lindsay Lohan";
dump(foo.startsWith("Lindsay"));
</cfscript>
Yes, the .startsWith()
and .endsWith()
methods are part of the java.lang.String
class, which is under the hood. This is one of those things that’s “kind of known”, but never explicitly documented to be OK to use. All I’m talking about is essentially taking those methods and exposing them (more or less) as CFML-native operators.
Meaning, that contains
and does not contain
operators are likely little more thin layers over .indexOf()
in the Java layer. But, have more CFML semantics.
Plus, the Java methods are likely case-sensitive, whereas CFML operators are usually not case-sensitive.
5 Likes
bump, some of these string methods are not exposed in cfml either.
would be great to see these documented, perhaps with some kind of native java annotation.
You can always access the underlying java methods, but they aren’t cfml functions, if you want to use java methods, you can, read the java docs, or dump out the class
<cfscript>
dump("lucee".getClass())
</cfscript>
Firstly, it’s totally fine to use them, they are available depending on which version of java you are using and you know the variable is the correct type.
Lucee 6.2 does better auto casting when passing arguments into such functions, but that’s the extent of how we can make them “CFML-native” other wise, we would be re-inventing the wheel.
2 Likes
I love using the Java layer when I can. The only light push-back I’ll offer is that with the rising popularity of member methods in CFML, it can sometimes be surprising when you “accidentally” invoke a Java method thinking it was a CFML member method.
For example, there was a good chunk of time where I thought it was ok to run:
fileObject.close()
I had assumed that this was the member version of calling:
fileClose( fileObject )
But, as I came to learn (after debugging strange file-access errors) that .close()
was not the same as fileClose()
; and in fact, I was accidentally accessing the underlying Java object, which wasn’t cleaning up stuff the same way that the CFML layer would have.
Again, not saying using the Java is “bad” only that it can be surprising 
1 Like
and we only made it worse by making both cfml and java member functions even bloody faster in 6.2, BIFs are still faster tho, as they aren’t dynamic
note to self, good slide for the CFCAMP keynote!
3 Likes
Oh man, the jump from 5.4 to 7.0 is crazy 
1 Like