TAG Meeting Minutes November 24th @ 8pm UTC

language tag
1

The next scheduled TAG Meeting is November 24th @ 8pm UTC. Any TAG members not in attendance will be drawn and quartered.

Agenda items

2
  • Custom Tags as CFCs - pros/cons/flaws — should that be supported in the future?
3

Thx, added to the agenda.

4

Lucee Technical Advisory Group (TAG)
Meeting 4
Date/Time: 24th November 2015 @ 20:00 UCT
In Attendance: Brad Wood, Simon Hooker, Kai Koenig, Luis Majano, Mark Drew, Dominic Watson
Absent: Sean Corfield, Igal Sapir, Micha Offner

Summary of votes taken in this meeting
Full details of the discussions surrounding these tickets can be found in the minutes below

Meeting minutes

  1. Approve meeting minutes from last meeting
  2. Documenting/publishing the ticket workflow
    • Discussion
      • There needs to be a reference for what each stage means, i.e. that “Added to Backlog” is a good thing.
    • Conclusion
      • Action Dom to create a flow chart based on the Jira Enhancement workflow with a sentence or two about each step
  3. New Kanban board for rejected tickets
  4. Custom Tags as CFCs
  5. 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-249 change lambda syntax from → to =>
      • Discussion
        • Java uses → but JS uses =>
        • CF devs potentially more likely to be using JS alongside CF
      • Conclusion
        • Vote taken
          • [ 9 votes ] Add LDEV-249 to backlog
          • [ 0 votes ] Reject LDEV-249
          • 0 abstentions
    • LDEV-82 Preventing Method Injection
      • Discussion
        • In a dynamic language this shouldn’t really be enforced
        • This feels more like a developer trust issue
      • Conclusion
        • Vote taken
          • [ 9 votes ] Reject LDEV-82
          • [ 0 vote ] Add LDEV-82 to backlog
          • 0 abstentions
    • LDEV-64 Feature toggle system
      • Discussion
        • Comes back to ACF compatibility
        • There are already various toggles within the Lucee admin
        • Potential future discussion for how to move away from any need for feature toggles
        • Can “undesirable” functionality that users may still wish to use for compatibility be moved out
      • Conclusion
        • Vote taken
          • [ 9 votes ] Reject LDEV-64
          • [ 0 vote ] Add LDEV-64 to backlog
          • 0 abstentions
    • LDEV-54 Improve onFinally()
      • Discussion
        • The ticket has some merits but it’s not clear what is needed, so the ticket will be reopened and set to public consultation.
      • Conclusion
        • Further public discussion required
    • LDEV-46 Formal mix-ins
    • LDEV-60 Add assert statement
      • Discussion
        • Discussion over use cases of this functionality happened with some cases for and against.
      • Conclusion
        • Vote taken
          • [ 7 votes ] Reject LDEV-60
          • [ 2 vote ] Add LDEV-60 to backlog
          • 0 abstentions
  6. Date of next meeting 9th December 2015, 20:00 UTC
5

My votes:

LDEV-249 change lambda syntax from → to =>: Approve
No-brainer imho

LDEV-82 Preventing Method Injection: Reject
Rejected that idea because I think it’s the wrong approach for a dynamic language.

LDEV-64 Feature toggle system: Reject
The influx of feature toggles as of now is terrible, I think Lucee needs a very clear decision on what the language will and should be and that’s it. No “oh, let’s add a toggle here to customise stuff” anymore please.

LDEV-54 Improve onFinally(): Move to public consultation
I was quite negative on this initially. After we had a discussion about CFC-based custom tags in the TAG, I now think that this ticket might make sense, provided CFC-based custom tags get proper documentation and proper support. Deserves being moved to Public consultation regardless.

LDEV-46 Formal mix-ins: Move to public consultation
Again, this is interesting. I like the PHP concepts @adam_cameron linked in the original ticket, and I think this idea warrants at least further consultation/discussion.

LDEV-60 Add assert statement: Reject
Against this idea and pro-reject for fundamental reasons. I think assert statement in the provided context is plainly a bad idea and leads to developers not dealing with error handling properly.