Is there a future plan for

isValid

to be allowed as a member function?

Search the issue tracker. If you don't see any tickets, the answer is "no" 🙂

just did a search for lucee issue tracker... is this the right place? https://luceeserver.atlassian.net/jira

Yup, that's the place

https://luceeserver.atlassian.net/browse/LDEV-63 Thanks for entering this in @Adam Cameron.... BACK IN 2015! 🤣

I could give it to you, but I literally just google "adobe ticket tracker" every time I want to find it.

well, I did search first, which is why I asked afterwards, because I'm not finding it, or at least nothing in the list or what I have clicked on in the search looks legitimate. Not trying to be lazy here by asking, but I didn't imagine this would need so much searching to find the the correct one.

It's the third result on Google for me

thanks, my third one is https://helpx.adobe.com/x-productkb/policy-pricing/customer-support-portal.html

It's a shared ticket tracker

I see

Good luck, lol

correct

anyRandomVariable

must first be a type that the CF engine has defined to have that member function. Which makes them fairly useless in any sort of libraries or frameworks which need to dynamically handle diverse inputs

just tested your example. interesting that it works as a regular function and not as a member function. Totally different behavior

oh gosh yes

Right, how is it acceptable to have totally different behavior when, in theory, the functions are to expected be exactly the same when the function name is the same name.

It's not really that

len()

"behaves" different. it's that it doesn't exist on those data types.

that makes sense

You have the same issue when you do this

myMap = createObject( 'java', 'java.util.HashMap' );

structInsert( myMap, 'foo', 'bar' );
writeDump( myMap.keyArray() )

but I would argue then that if it doesn't do what it should compared to it's regular function, then the behavior is different. The result is not as expected. If ACF is looking at this member function to decide if it is an array, struct, or string, and the regular function is not doing that, then isn't it considered a change in behavior?

It's a behavior change of the language

🤘🏼

The engineers for both engines have always claimed it would be a hit to performance to detect what the type is at runtime. I'm not entirely sure how that differs from the checks/casting that already happens inside the headless forms of the functions

when checking for member functions, lucee doesn't cast, it checks the type https://github.com/lucee/Lucee/blob/6.0/core/src/main/java/lucee/runtime/util/VariableUtilImpl.java#L788

It would be great for devs not to have to be in this constant state for so many years of wondering what function is or is not a member function. It would be great if every function is usable as a regular or member function. I would assume that this idea would make it a very time consuming task, but it is just one of those annoyances that has been hanging around for years. I get that there is only so many of you and capacity work load is limited and I appreciate what Lucee has done and its current efforts for the CFML community. I just wish there were some of these loose things that devs grapple with on a daily basis to get tied up.

my usual internal dialogue is, does this BIF start with (struct, list, query, array) then there's a member function

Understood. Are you having this internal dialogue based on limitations by having to pick and choose based on projects that have a higher priority or is this idea of these pre-fixed BIFs what it should be permanently? In a previous life, I coded in RoR. I am not attempting to say that I want everything like RoR or Python, but the door opened with the first member function available in CFML. I loved the fact that, in my limited time in RoR (many years ago), it was a great feeling knowing that I could write everything as a member function. There wasn't any guessing and/or testing, discussing, etc. In CFML, I just wonder how much wasted time we spend as devs in all of these companies around the world checking to see what is and is not a member function. I am definitely willing to be enlightened, if my premise (which is very basic in the Java world) is totally incorrect.

I see no reason why there's not a notion of

isValid

that can be a method of at least some of CFML's data types. eg:

myString.isValid("date")

has sensible meaning.

myArray.isValid("uuid")

... not so much 😉 However, as @bdw429s points out, that's not as useful as it could be, in generic situations; and also not as flexible as the top level functions can be given the "flexibility" CFML shows in its type handling. There's also something to be said that type checking (or "type interpretability", which is all

isValid

is doing) is perhaps better left to a level outside the type system itself. --- I think this discussion comes back my frequent observation here: it's just a misunderstanding of "how things work" in OOP that leads to the expectation that

someFunction(somethingUsableHere)

should have a direct mapping as

someConcreteThing.function()

. It's easy to confuse one's self when there are identical words in play:

ArrayMap()

and

Array.map()

, but one needs to understand the usage of

array

in the first one does not mean the same thing as in the second one: same word, two different (and legitimate) usages.

ArrayMap

does not take an array as a first argument in the same sense that there is an

Array

type in the second one. The function signature of

ArrayMap

would be something like:

Array ArrayMap(SomeVagueArrayInterface a, function f)

, whereas when we talk about

Array.map

it is a specific method on that specific Array class. That's just how OOP works. There is no confusion in the reasoning for the implementation, there is just confusion on the part of CFML devs migrating from procedural to OOP CFML.