Lucee Technical Advisory Group (TAG)
Date/Time: 27th January 2016 @ 20:00 UCT
In Attendance: Brad Wood, Simon Hooker, Dominic Watson, Sean Corfield, Mark Drew, Igal Sapir, Micha Offner, 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
Approve meeting minutes from last meeting
- Micha has been working through the tickets in “New” status to reduce the number of tickets that have not been handled
- Tickets labelled Velvet are intended to be included in the 5.0 release
Lucee dialect discussion
- Most of the TAG members have submitted their opinion following previous meeting.
- The LAS management board will include this in their next meeting
- The Lucee dialect is not going to hold up the release of Lucee 5.0 so there’s no urgent requirement to decide on this at this time.
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.
LDEV-672 Add Hooks for Java Event Listeners
- Feedback on the currently available features from the devs
- We already have “monitors” in Lucee, request, intervals, and action monitors.
- These monitors are used in various extensions already.
- Monitors only listen and throw exceptions.
- Any implementation of this would need to extend the current implementation
- Monitors don’t necessarily follow any standards
- Any new implementation would need to be backwards compatible to prevent breaking extensions running on the existing behaviour.
- The current implementation was in favour of what one developer needed, and suggestions for modification would instead be in favour of another developer - a middle ground is required.
- The suggested implementation on LDEV-672 is not potentially too far from what already exists
Action Micha Offner to document existing functionality
- Ticket to be returned to public consultation for clearer definition
LDEV-449 Redefining truthy and falsey values
- This ticket was dicussed due to having some extra time available
- Concerns about backwards compatibility raised
- The “String” options in particular caused problems. If it an empty string returns false, but “no” and “false” also do then the falseyness of an empty string cannot be used to determine whether the string is empty.
- The current implementation of the elvis operator, as has been previously discussed, is not implemented the same way as other languages.
- As compromise on LDEV-449, the empty string being falsey has been removed and will be discussed on a future ticket.
Date of next meeting 2016-02-10, 20:00 UTC