"startswith" and "endswith" operators

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 :smiley:

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 :smiley:

1 Like