http://coldfusion.com logo
Join Slack
Powered by
<@U06V253M4> what's your opinion of this behaviour...
# cfml-general
a
@bdw429s what's your opinion of this behaviour (either platform): https://trycf.com/gist/7247e6a46178f1a9cc15164d5b2c0e51/acf2021?theme=monokai To me, it's a fundamental of a mapping operation that the result type should be the same as the object being mapped. Or is this just something on the periphery of CFML's "partial" (or just "poor") implementation as a JVM language that means it's legit for the type to be changed to the "native" type here?
l
I would agree that a mapping operation should return the same type. That said, stepping back, you're are taking a CFML object, then using a java method on it which coerces it into a java object. Then taking a java object and using a CFML function on it which coerces it back into a CFML object.
As an aside, I haven't touched ACF in years and recall abhorring the Lucee dump colors when switching over. Running your code on both engines, I've come to like and, in this case, appreciate those differences.
d
Hmmm if you were using member functions I would be in the camp of “must return same type as the object” but because this is a coldfusion stand alone function called arrayMap it is clearly telling you the type to expect which to me is a cf array.
b
@Adam Cameron Interesting observation. While I've never heard either of the CF engines advertise map() as returning the same type, that's pretty much the standard in any language. I suppose there's some wiggle room on "types" in CFML as arrays are sort of anything that can be coerced into an array. So both the native java array and the CFML array would pass the 
isArray()
check-- so they are "arrays" at some high level. I'd be reticent to call this a bug-- if I had to choose, I think I'd rather have BIFs favor returning a native CFML type SO LONG AS important behaviors weren't lost. i.e., if you were using a specific sub class of java.util.List with additional methods/behaviors, you'd not want that lost. But in this case, the original array wasn't even an instance of a Java class-- it was just a pure native array of strings.
Copy code
[Ljava.lang.String;
So at any rate, a CFML array would be a superset of that. That's not to say there's another another example out there which may not be as desirable.
⭐ 1
d
JavaScript's Array.prototype.map() method always returns an array, regardless of what type of object you feed it (e.g. Array, NodeList, HTMLCollection), so CF's behavior is not unprecedented.
a
@David Buck I do not see a map method on NodeLists or HTMLCollections? (ref: https://developer.mozilla.org/en-US/docs/Web/API/HTMLCollection, https://developer.mozilla.org/en-US/docs/Web/API/NodeList)
d
I was talking specifically about the 
map()
function that is an instance method of the built-in 
Array
object. Like CF's 
arrayMap()
function, you can feed it objects that technically aren't JavaScript Arrays (via 
Array.prototype.map.call()
), but it always returns a JavaScript Array. I don't know if any other types of objects have a 
map()
method, but if they did, they'd presumably return their respective types instead of arrays.
Example:
Copy code
const obj = {0:"foo", 1:"bar", length:2};
console.log(obj); //returns Object { 0: "foo", 1: "bar", length: 2 }
console.log(Array.prototype.map.call(obj, x => x)); //Returns Array(2) [ "foo", "bar" ]
a
Oh! Interesting. Yeah, that's a good analogue.
4 Views
Open in Slack
PreviousNext
Powered by