I heard about this on a podcast, would be a neat e...
# cfml-general
z
I heard about this on a podcast, would be a neat extension to ListToArray https://github.com/tc39/proposal-reversible-string-split
👍🏾 1
d
Hmmm would love to hear any real world use cases for it other than it be neat.
I could maybe see 1 use in graph traversal assuming the graph is stored as a string.
d
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?
z
Totally, it would stop string parsing after N and it's rather useful to have the remainder
d
cool
z
So we could support -N which would abort and not populate the last array element with the remainder
👍🏾 1
a
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.
rubber duck 1
☝️ 1
a
Yer not implementing "Zac's Neato Lib (TM)", yer supposed to be implementing a solid implementation of CFML. So focus on that.
z
says who?
a
Anyone who has any sense about what Lucee is supposed to be.
(so yeah, I don't necessarily know who those ppl are, based on recent experience. Good point)
z
why are you so grumpy mate?
I'm not allowed to propose things?
a
You absolutely are. You just did.
I presumed you proposed it to get feedback.
And there. That was my feedback. This is how this whole "propose an idea and accept feedback" thing works.
z
on the topic
you asked years ago for us to add usgage notes to lucee docs, so i did it and you never used it, all you do is comment from the gallery and never get your hands dirty
a
I don't know a) what that means; b) how it's relevant here (although obvs (a) informs (b) here).
You are asking in "the gallery".
z
as an actual contributor
a
Did you just expect "yeah Zac, just go do that"?
I don't really see how your ad hominem approach helps here. You could maybe address the points I made, rather than attempt to invalidate them because I'm in the very peanut gallery you asking the question in.
z
well, all i expect from you is mostly snarky comments
a
I think you are confusing "not what you want to hear" with "snarky comments".
But so be it. You do you. You asked for input: input delivered.
z
thanks, noted.
d
@Adam Cameron Why do you think ACF should implement it first? I honestly thought Lucee branched off a long time ago.
a
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".
z
Brb implementing string.len()
Lucee has it's own identity beyond being just an ACF clone. This proposal was based on most other major programming languages support it
👍 1
a
"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
Copy code
s = "a|b|c|d|e|f"
writeDump(s.split("\|", 2)) // ["a", "b|c|d|e|f"]
👍 1
d
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.
But I see it works
e
split
drops down to Java’s
String
class.
✅ 1
Which is a little tricky because you get back a Java
Array[]
and not a CFML array. I usually use
arraySlice( arr, 1 )
to then convert it back to a CFML array.
Most CFML functions know how to take a Java array and wrap it, but don't try calling member functions on it without converting it first (from personal experience).
✅ 2
a
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.
d
This brings me to unfamiliar territory. Still trying to wrap my head around this. split() returns a
Native Array (java.lang.String[])
Copy code
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
l
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.
e
@Daniel Mejia The general rule is no member functions. The standalone functions convert the Java array to a CFML array.
👍🏾 1