ACF-2018 compatibility

language
1

We started a document to keep track on all features new to ACF-2018

ATM we have 4 categories:

  • already supported (green)
  • partially supported, maybe needs some adjustments for an exact fit (orange)
  • not supported (red)
  • not sure (white)

Next step is, we make Jira tickets for every single point in that sheet.
Feel free to comment in every upcoming Jira ticket and vote for the feature you like.

1 Like
2

this pdf (login required) details the changes in depth

3

Here’s some attached versions for anyone who doesn’t have a login to the Adobe community portal.

files_2018_04_Public_Beta_Whats-new-and-changed.pdf (43.8 KB)

files_2018_04_Public-Beta_Documentation.pdf (932.5 KB)

4

this script shows me the difference with named arguments, in addition it also shows missing functions and functions with a different argument length.

1 Like
5

Based on page 22 in this doc
https://lucee.daemonite.io/uploads/default/original/2X/1/1c29797ce9e661597e19f21e172eda67d4db5757.pdf

this code

a=[1,2,3,4,5,6,7,8]
writedump(a[1:6])

should produce this output
[1,2,3,4,5]
but in my opinion it should be
[1,2,3,4,5,6]

then end index is 6 what has the value 6, do i miss something?

1 Like
6

@micstriit A quick review of other languages (JS, java, Python) the ending index is not inclusive meaning it’s “up to but not including”. I would prefer both indexes be inclusive but there seems to be a precedent there in other languages I Adobe probably followed.

7

@bdw429s when introducing new features into Lucee i always look for existing features that are similar to adapt, in that case i would take the function “mid” as template as we did for the function “ArraySlice”.
what is “offset” and “length”.

8

here is the update 1, mostly changes to named parameters

9

implementing typed arrays are not possible in Lucee as they are implemented in ACF.

arrayNew["string"](1);

Lucee supports to use bracked notations to call functions, so the following function call of a component

mycomp.setName("Susi");

can also be done as follows

mycomp["setName"]("Susi");

what allows to set the name dynamically

funcName="setName";
mycomp[funcName]("Susi");

This syntax conflicts with the syntax chosen by ACF for this typed arrays.
Seems they adapted generic types from Java, but in my opinion a bad solution.

Better would be

arrayNew(1,"string");
arrayNew(type:"string");// named arguments
10

arrayNew(1,“string”); means synchronized?

11

@Zackster good observation!
With 5.3 we move the attribute “synchronized” to the end of the argument list, so it will be

arrayNew(dimension,type, synchronized);

BUT Lucee 5.3 is backward compatible to 5.2, means if someone does

arrayNew(1,true);

it will still work because the function detects if “type” is cast-able to a boolean, in that case it uses the value for “synchronized”.
It is not the first time we handle this in that way and normally this does not cause any problem for existing code.

we also discussed to make the argument “synchronized” obsolete, like we did for structs in the past (structNew("synchronized")). In Lucee all structs are synchronized. So the idea is to make all arrays synchronized.

12

Hi @micstriit, What if arrayNew(1,true) represents a CFC named true.cfc? That’s edge-case, so no need to cater to it right? Thanks!, -Aaron

13

Hi @micstriit, Agreed. This is fixed in latest public Aether refresh. Thanks!, -Aaron

14

yeah that would be a problem, similar to name a cfc for example String/Date/Numeric/Query/…
and then use that as a type definition.

function test(Query q) {
}
test(new Query());
test(queryNew('a,b,c'));
15

there’s a discussion of this syntax in the ACF forums, might be worth chiming in?

16

@Zackster thanks to point out, seems the discussion already goes into the right direction.

17

Ben Nadel has been investigating the new futures / runAsync in ACF 2018

I see there is a very old issue about this [LDEV-311] - Lucee

Is there a plan for supporting this in Lucee? (BTW I just got an access denied on that google docs spreadsheet?)