I heard about this on a podcast, would be a neat extension to ListToArray https://github.com/tc39/proposal-reversible-string-split

Hmmm would love to hear any real world use cases for it other than it be neat.

Is there a memory or speed aspect to this feature? Lets say I only need

N-1

, in other words, I do not need the remainder. Is there less memory used OR speed gain if the remainder is never split to array items?

Totally, it would stop string parsing after N and it's rather useful to have the remainder

cool

So we could support -N which would abort and not populate the last array element with the remainder

would be a neat extension to ListToArray

No. Not unless Adobe do it first. Stop implementing shit that's different from CFML. And given you are apparently so under resourced that you can't do things like keep your dependencies up to date... stop doing anything that isn't pressing.

Yer not implementing "Zac's Neato Lib (TM)", yer supposed to be implementing a solid implementation of CFML. So focus on that.

says who?

Anyone who has any sense about what Lucee is supposed to be.

why are you so grumpy mate?

You absolutely are. You just did.

on the topic

I don't know a) what that means; b) how it's relevant here (although obvs (a) informs (b) here).

as an actual contributor

Did you just expect "yeah Zac, just go do that"?

well, all i expect from you is mostly snarky comments

I think you are confusing "not what you want to hear" with "snarky comments".

thanks, noted.

@Adam Cameron Why do you think ACF should implement it first? I honestly thought Lucee branched off a long time ago.

Yep they did. And initially I thought that was a good idea. However as time passes having all the CF incompats seem to be more of a problem than a benefit. I also think their resources are spread very thinly, and whilst there are acknowledged CF incompats that they know about and have flagged to fix: they should be focusing on that lot before they bring other small incompatible features into the mix. I have also watched the CFML community for some years and I deeply regret not being more active in encouraging Railo to focus on being the best free proxy of CF's reference implementation of CFML that they can be. Ultimately think it has diluted Lucee's merits. That said, I'm all for them developing all the incompats they like, provided they are implemented in optional add-on libraries, rather than diverging the core Lucee baseline CFML implementation. --- Now... we are where we are, and that's fine (well...). However if I'm asked for input into a suggested feature... even if I'm only in the peanut gallery and that somehow invalidates my opinion when it conflicts with how ppl want things to be... I will still say "nah, I reckon you should focus on being compatible with CF and don't worry about largely inconsequential & incompatible tweaks".

Brb implementing string.len()

"Most" other major programming languages don't have the concept of lists in the CFML sense of the idea. Plus... Well... Um... CFML (both CF and Lucee) already support exactly what you are talking about anyhow. Not a special Lucee-only list version, but exactly what you are talking about (as per that original github link). https://trycf.com/gist/dc7592e95c22bcff32b716565ae8b473/lucee5?theme=monokai

s = "a|b|c|d|e|f"
writeDump(s.split("\|", 2)) // ["a", "b|c|d|e|f"]

Wait what. A quick search for that function in lucee and adobe didn't render any results and it's not in the lists of string methods. Cfdocs doesn't have it either.

split

drops down to Java’s

String

class.

Yeah and this sort of thing is why I chuckle a bit when ppl say CFML is a JVM language just like Groovy / Scala / Clojure / etc. Its Java interop isn't quite there (for various historically valid but somewhat hindsightfully-disappointing reasons). But anyway, yes: strings in CFML are java.lang.Strings, so one can use its methods as well (in this case https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/String.html#split(java.lang.String,int)). This is by design. And one has to understand that calling

someFunction(obj)

is not the same as calling

obj.someMethod()

.

someFunction

is a discrete implementation, and

obj

can be any type that it chooses to support, and it will handle type coercion / conversion internally. With

someMethod

it is part of the implementation of the class of the object it's called on. So CFML functions will take a Java array and internally convert it to something it can work with; however one can't hope to call one of CFML's array implementation methods on a Java array because they're two different things. All CFMLers ought to know this, and it should not come as a surprise.

This brings me to unfamiliar territory. Still trying to wrap my head around this. split() returns a

Native Array (java.lang.String[])

a = "1,3,3,4,5"
b = a.split(",") // OK - returns native array "java"

/****** Which methods work? ******/
c = b.slice(1) // No matching Method/Function for [Ljava.lang.String 
c = arraySlice(b,1) // OK
c = b.avg() // No matching Method/Function for [Ljava.lang.String
c = arrayAvg(b) // ok

I see no problem with Lucee adding new functionality from what Adobe provides. First off, I'm sure some of that work has been an impetus for Adobe to eventually add that functionality (often, implemented differently, so yes, I acknowledge that point) Second, my experience on all of the previous Adobe pre-release programs seems to show that they are more focused on adding enterprisey modules than adding core language features and the feedback on those programs have been almost non existent the past few releases. The average group text thread on my phone over where to go for a drink this Friday has more activity than a week of that program! So Lucee acting as a canary in the coal mine for pushing the CFML language forward seems just fine to me here and I applaud it.

@Daniel Mejia The general rule is no member functions. The standalone functions convert the Java array to a CFML array.