would like to see LDEV-42 and other simple language improvements prioritised at some stageā¦ still ānewā even with supportā¦ yet new fancy stuff most will never use is getting priorityā¦
I also er LDEV-720 something Iāve stopped adding to trackers for listDeleteAt(string,-1) to remove the last element or listDeleteAt(string,-3) to remove the third last element in a listā¦ #longtimefrustration having to use listLen(string)-1 all the time grrrr. glaring omission.
just found LDEV-520 - is that a joke that itās still outstanding on basic IMAP support for folders, yet weāre having meetings about new functionalityā¦ move the whole 1980ās email out of adminā¦ introduce 2016 āmessagingā (which includes plugin with current functionality for backward applications compatibility, allowing for a breath of fresh air in this stale part of the admin)
there are a few basic lang updates there in the tracker that can be knocked off easily and would make even 4.5 coders a sigh of relief after years of waitingā¦ 42 is an example, as is 520
Re: LDEV-42 - Iām neutral-to-positive on these (I donāt see enough value in them to be part of the core language but I can see why folks might appreciate them).
Re: LDEV-720 - Iām against DeleteAt() ā I think theyāre horrible methods (too specific) and Iām against encouraging more list functions anyway. The negative index in other functions thoā, yes, absolutely makes sense.
Re: LDEV-520 - Like Iāve said there, move to an extension, get the community to contribute.
We asked the LAS management board for some clarification on the direction of LuceeLang and where it fell in the LAS priorities. Our discussion on their reply will be in the meeting minutes from last week that @simonhooker is working on. Iām also checking into making our private discussion about the matter public just to help show the conversation.
At present not all votes are finalised - the current counts reflect votes currently cast
Date/Time: 10th February 2016 @ 20:00 UCT In Attendance: Brad Wood, Simon Hooker, Dominic Watson, Mark Drew, Micha Offner, Sean Corfield Absent: Igal Sapir, Kai Koenig, Luis Majano
Summary of votes taken in this meeting Full details of the discussions surrounding these tickets can be found in the minutes below
Community expressed concerns that declaring a scoped variable as private or public makes no sense.
The precedent for this was set by functions which are also defined in the āthisā scope however have access modifiers implemented.
Opinion expressed that this is an ACF incompatiblity and something that is halfway towards Java.
āprivate lastnameā should create āvariables.lastnameā but āprivate this.lastnameā should be a compiler error. Similarly āpublic lastnameā could create āvariables.lastnameā.
There is already functionality that allows the default access modifier for the āthisā scope.
Action: Simon to create a ticket and add to the voting list for this meeting to decide on whether or not to remove this feature from Lucee 5.0
Action: Simon to create a ticket to discuss how to implement this feature ( this assumes a āRejectā vote on previous ticket )
Review enhancement tickets
A selection of existing proposals and enhancements were selected for review during this TAG meeting. Not all selected tickets were able to be discussed within the time allowed.
This change will allow handling where at present an illegal exception is shown.
The expected behavior will need careful documentation to ensure it is clear how it would function differently to ACF.
Potential for users to be able to override the default behavior to enable users to customise how data types are parsed when converted to boolean. This option was met with criticism.
Conclusion
Action Subtasks to be raised for each data type and votes to be taken for each data type sub-task
Concern about how sub-array elements would be handled
Generally seen as something that should be achieved with a user defined function rather than a part of the general language
Conclusion
Vote taken - Reject ( 7 - 2 )
LDEV-698 - Make retry settings for email sending configurable
Discussion
This ticket is for a new attribute on the cfmail tag
A precedent for this logic exists in cfthread
Conclusion
Vote taken - Accept ( 9 - 0 )
LDEV-709 - struct.clone() does not reliably preserve types of cloned child fields
Discussion
This ticket appears to be more of a bug
Dev explained how the clone function behaves and why this is a problem.
There is not a simple fix for this
Similar to the functionality requested in LDEV-689 but different in that an exact copy is desired rather than having any concern about how to handle key conflicts
Option 4, calling clone only if ādeepCopyā is set to true, suggested as a solution and put to a vote.
Conclusion
Vote taken - Accept ( 9 - 0 )
Action: Documentation to be updated to more clearly communicate the behavior of cloning
LDEV-715 - Ability to create a Cache Connection from Application.cfc
Discussion
Certain settings canāt be applied to the Application.cfc due to chicken-and-egg issues. Application.cfc can only cover runtime behavior.
Opinion in favour of allowing every runtime setting be able to be configured in the Application.cfc
Conclusion
Vote taken - Accept ( 9 - 0 )
Action: Create a matrix of features in the admin that could be exposed as configurable into the Application.cfc