Well yes, lol. You’re the one who brought up the JOSN here.

True I got the JSON error first and then set about replicating it which led me to the cause, so just chucked all my code to reproduce the issues on here. In hindsight I sound have not included that JSON part and done it as a separate ticket (which I now have)

I’d ignore the JSON stuff for this ticket as it’s just a symptom, the compatibility issue here is what’s being assigned.

Well yes, lol. You’re the one who brought up the JOSN here.

It’s important for UDF declarations to override anything already in the variables scope so inheritance works correctly, but I’ve added a somewhat-janky workaround in the pseudconstructor to change the order things initialize in.

1. UDFs registered

2. Properties defaulted

3. Custom pseudconstructor code runs

And furthermore, properties previously would not override existing values so any logic that set a property value in a super class wouldn’t be “undone” by a default value in the concrete class’s property declaration. I modified that so property defaults WILL override existing values in the variables scope if they are functions. Feels sort of arbitrary, but it will at least match CF’s weird behavior. I don’t think this CF behavior was ever “planned” per se, I think it’s just how Adobe happened to implement it.

So this means if you have

in a class also having

the property default value will “win” in the variables scope.

But if you have a superclass pseudconstructor with

then the UDF in the concrete class will “win”.

I’d ignore the JSON stuff for this ticket as it’s just a symptom, the compatibility issue here is what’s being assigned.

As for JSON I think it’s correct that it doesn’t recurse itself to death. The difference here to ACF / Lucee is that it doesn’t recurse as it handles serialising a function (although what use it is I’m not sure!). I’ve created a new issue for this specifically

Caused by: com.fasterxml.jackson.core.exc.StreamConstraintsException: Document nesting depth (1001) exceeds the maximum allowed (1000, from `StreamWriteConstraints.getMaxNestingDepth()`)

Prolly not much to “fix” there. I assume the function contains circular references so this is just the Jackson lib’s stack overflow prevention kicking in. I assume if you ask it to serialize something not recursively nested to infinity, it works?

A better question is what would you expect CF/BL to do when asked to serialize an infinite data structure??

• Adobe CF recurses about 1500 times and then just stops

• Lucee returns null after the first recursion is detect

• BL gets an exception thrown from the 3rd party Jackon Java lib we use

I would say BL’s behavior is the least “useful”, though I’m not sure what control we have over Jackson in this case. It’s intersting to note, when it comes to dumping the same thing

• Adobe’s dump recurses a bunch of times and then just stops

• Lucee detects the recursion after one time

• BL also detects the recursion after one time

I’m able to match Lucee’s behavior in BL for dumping since I handle the recursion myself. Our JSON serialization right now is 100% done by the 3rd party lib.

I’ve added the stacktrace for the SerializeJSON error. That’s really a symptom though. I may raise another ticket with an example of that on it’s own.

I was surprised that this worked in ACF and Lucee when I was trying to find the cause - but it does so I guess it’s “correct”

The way you have it working makes sense for BoxLang, up to you if you want to support the ACF / Lucee implementation for bx-compat.