TAG Sept 16th Meeting Minutes

language tag
1

This one has come up a little quickly after our kickoff meeting. To get our feet wet and help work through some old stuff clogging up JIRA I asked @simonhooker to help pull together some tickets for us to discuss. Meeting will be via Zoom. The URL or call-in number is in the Google calendar invite I just sent out.

Meeting date/time is as follows:

  • PST Wednesday the 16th @ 12 pm
  • CST Wednesday the 16th @ 2 pm
  • UK Wednesday the 16th @ 8 pm
  • CH Wednesday the 16th @ 9 pm
  • NZ Thursday the 17th @ 7 am

Agenda Items

We don’t have to make it through the entire list. I would recommend we decide if each idea is even defined well enough to bring it to a vote. If not, we’ll add comments to the ticket and leave it pending. If so, we’ll prepare a spreadsheet for the members to enter their votes into. The voting can actually happen later at each member’s convenience after the meeting (especially if anyone is absent) and we’ll simply tabulate the responses and include the outcome in the meeting minutes which will be added here in this post.

2 Likes
2

Date/Time: 16th September 2015 @ 19:00 UCT
In Attendance: Brad Wood, Simon Hooker, Kai Koenig, Sean Corfield, Igal Sapir, Micha Offner, Mark Drew, Dominic Watson
Absent: Luis Majano

Summary of votes taken in this meeting

Full details of the discussions surrounding these tickets can be found in the minutes below

  • LDEV-369 Add a require semicolon or a “ACF mode” - Rejected ( 5 - 3 )
  • LDEV-438 Allow exceptions to be nested - Accepted ( 9 - 0 )
  • LDEV-442 Array function to remove duplicates - Accepted ( 7 - 2 )

Meeting minutes

  1. Approve meeting minutes from last meeting
  2. What is the TAGs definition of “compatibility”
    • Discussion
      • Should it be assumed that anything we approve as an “enhancement” that is not in ACF be only made to Lucee, or should it be in the CFML interpreter?
      • ExpandPath used as an example Lucee has a ContractPath method that is not in CFML. Should these be removed for CFML compatibility?
      • Best to not make a general decision and decide case to case
      • Used to need to define var scoped variables at start of a function. Railo allowed var to be used everywhere.
      • What is “compatibility”?
      • CFML compatibility means that an ACF program runs unchanged in the Lucee CFML mode.
      • Anything that Lucee adds that does not break compatibility is fine
      • This renders LDEV-369 to not be a compatibility issue as it doesn’t prevent ACF code from working and so no need to remove “optional” semicolons
      • Option to add “strict” / “classic” code style options such as requiring semicolons?
      • Important not to take away something that Railo/Lucee users are probably using because this would break code that works on existing Lucee versions
      • We can do things that allow new functionality
      • Why is this a “Major” priority?
      • Action Change default Jira priority to be “new” or something similar. Simon completed this action on 2015-09-16
      • If we add a function and then Adobe also decide to add it, how should we then decide? Not a problem right now, discuss that issue when it happens.
      • We don’t want to just end up writing a clone of ACF without being able to add something useful, new functions can easy be polyfilled by users.
      • Feature flags can be difficult as it requires reconfiguring the server when you port code to allow it to compile.
    • Conclusion
      • Features that only exist in Lucee that aren’t in ACF today will not be removed.
      • Going forwards we are ok with adding new features to Lucee CFML as long as it does not break compatibility when users move code from ACF to Lucee.
  3. What’s the difference between Proposal and Enhancement?
    • Discussion
      • A proposal is something that’s proposed by someone and when the TAG has decided on an action then it becomes an enhancement
      • If we have specific types for proposal then we can have a nice output on the website similar to PHP RFC
      • Once TAG has reviewed the ticket, a Proposal could change to Enhancement
      • Changing type from Proposal to Enhancement is like changing a status, should there even be separate types?
      • Potentially redundant to have two types.
    • Conclusion
      • Action Revise JIRA workflow to merge Enhancement and Proposal and improve workflow to more closely mirror the Enhancement/Proposal workflow. Simon completed this action on 2015-09-16
  4. 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-369 Add a require semicolon or a “ACF mode”
      • Discussion
        • See earlier discussion regarding “compatibility” as the sentiment there largely applies to this ticket.
        • This is more of a coding style issue than “strict”ness. Is “strict” the right term? “classic” vs “modern” also used.
        • Semicolons are not always optional within Lucee i.e. with the return statement.
        • There are precedents in other languages with “optional” semicolons require semicolons in cases where the statement is open to interpretation.
        • Leaving the “default” unchanged would prevent breaking existing Lucee code.
        • This should be a configuration option in the admin panel as well as through Application.cfc.
      • Conclusion
        • Vote taken
          • [ 5 votes ] Reject LDEV-369
          • [ 3 votes ] Add LDEV-369 to backlog
          • 1 abstentions
        • Reasons for rejection
          • Portability checking is the remit of a separate tool such as ColdFusion Builder
          • Unless Lucee decides to add a full strict ACF compatibility mode there is not much point in addressing the issues piecemeal
          • If Adobe wish to support all CFML that Lucee does they are welcome to do so, it is up to Lucee to ensure code that works on ACF also works on Lucee and not the other way around.
    • LDEV-393 Support java-style annotations
      • Discussion
        • Positive sentiment towards the idea expressed, but requests for specific use cases have been made.
        • Comments shouldn’t affect semantics of a program. Should be able to do this with proper annotation.
        • Javadoc comments are fine because documentation do not have semantic meaning. Anything with semantic meaning should be syntactic annotations.
        • It can be useful to annotate a generated CFML method with a Java annotation. New Relic used as example due to its ability to trace a specific Java function using annotations. This would be useful.
        • Unable to use pre-available socket libraries due to inability to annotate methods.
        • Would annotations need to be in precompiled source code? Yes it would need to flow through code gen and attached to the generated source code in the same way as the Java compiler.
        • Devs express concern that far more detail over exactly how this should look is required. In principle the TAG is in favour of this idea but more clarity is required before it progresses to a vote.
      • Conclusion
        • Action Create a thread in the Lucee Lang forum for further comment
        • Deferred This ticket was sent back for further discussion and clarification before a TAG vote is taken.
    • LDEV-438 Allow exceptions to be nested
      • Discussion
        • This is almost possible at present. Some discussion about implementation followed.
        • Sentiment across the TAG seemed that this would be a good addition
        • The current behavior is a result of the original Allaire CFML implementation but could easily be adjusted.
      • Conclusion
        • Vote taken
          • [ 9 votes ] Add LDEV-438 to backlog
          • [ 0 votes ] Reject LDEV-438
          • 0 abstentions
    • LDEV-442 Array function to remove duplicates
      • Discussion
        • Mostly entered to mirror existing ListRemoveDuplicates
        • Some sentiment against to reduce function explosion. Sure this could be nice but is it really needed?
        • Precedent already set by ListRemoveDuplicates.
        • Arguably more efficient to do it built in
        • How many people need to do this vs the weight of adding more functions and documentation to the system?
        • One of the whole CFML/Lucee lang promises is to make things easier than Java etc. This falls in the category of a shortcut function.
        • Could this be an extension? At present you can’t add a member function ( [].removeDuplicates() ) using an extension. Could be possible in the future.
        • This is easily done by users, there are better ways of implementing it which would argue against implementing the function.
        • This function could be considered to be useful and shouldn’t add much that is inconsistent with existing code.
      • Conclusion
        • Vote taken
          • [ 7 votes ] Add LDEV-442 to backlog
          • [ 2 votes ] Reject LDEV-442
          • 0 abstentions
    • LDEV-113 allow construct for ordered structs
      • Discussion
        • Strong recommendation to defer this for further discussion
        • In Railo 4.2 all structs were changed. Most people expect no order because a structure has always been unordered and an ordered struct has a performance cost.
        • Argument in favour of defaulting a non-empty structure to being ordered, while defaulting empty structures to being linked (unordered).
        • Suspicion against changing default behavior due to the effect it may have on existing code. Concern over choosing the correct syntax to prevent incompatibility with other engines.
        • Changing all to ordered would make the engine slower. How much slower it makes it is not quantified. This would be worth testing to see what difference there would be in real applications.
        • Multiple TAG members object to changing the default due to changing the meaning of the existing syntax.
        • Does changing an unordered structure to being an ordered one really make a difference? Historically structures have always been “unordered” and changing the default meaning of a structure could be a slippery slope.
        • No fundamental objections to providing a new syntax to create ordered structs.
      • Conclusion
        • Action Create a new Lucee Lang thread to discuss syntax. Igal completed this action on 2015-09-16 link
        • Deferred While the TAG is in favour of this in principle it has been sent back for further discussion on syntax.
  5. Date of next meeting October 7th 2015, time TBC
1 Like
3

My votes:

Vote on LDEV-369 Add a require semicolon or a “ACF mode”: Reject
Initially when I read the ticket I thought that this might be useful for a CFML compatibility mode. However the discussion we had during the TAG meeting made me reconsider and I agree with the majority that this is not a problem Lucee should deal with. Compatibility should be ACF->Lucee and we shouldn’t have to care for Lucee->ACF

Vote on LDEV-438 Allow exceptions to be nested: Add to backlog

Vote on LDEV-442 Array function to remove duplicates: Add to backlog
This was a tricky one imho - I think it can be hard to maintain a balance between useful additions to the function library and cluttering the language as a side effect. In this case I voted for an addition because I think that a) it’s useful and b) justified given there’s already a precedent with ListRemoveDuplicates. Yes, the functionality can be achieved by users themselves, but adding it is consistent with the existing library.

4

Vote on LDEV-442 Array function to remove duplicates: Add to backlog

wow, really… to me this a no-brainer… if it’s implemented in list, then it should be in struct and array for consistency… looks like we’re heading down the CF path already… wasn’t the point of lucee ‘consistency’

I think the TAG need to blog to this decision as it’s goes against the grain of the organization ideals.

Then again isn’t it the same people who blocked cfscript who are now controlling this beast… to the same end no doubt. #losingfaith

5

You do realise that “add to backlog” means that the ticket is accepted?

6

But it’s so piss-easy to roll yer own (it’s a single expression, see below), I don’t really think there needs to be too much urgency to is. It’s not like they said “will not fix”, they just figured there’s bigger fish to fry first. Which there are.

dedupedArray = array.reduce(function(deduped, el){
    return deduped.find(el) ? deduped : deduped.append(el);
}, []);
7

sorry used to dealing with Adobe, where backlog means ‘never’

8

Then again isn’t it the same people who blocked cfscript who are now controlling this beast… to the same end no doubt. #losingfaith

What on earth are you talking about? The TAG are a new group and I don’t believe we’ve made any decisions on cfscript at this point. Why are you being so negative?

http://lucee.org/blog/lucee-tag-finalisation.html

9

Just to generally clarify what “Add to Backlog” means:

The TAG has voted in favour that this will be looked at and implemented by the development team.

“Add to Backlog” has no positive or negative connotation either way re if something is urgent or not so urgent or when it’ll be done. Therefore even your interpretation of “bigger fish to fry first” is at this point not correct.

The development team might still reject stuff from the backlog if it’s crazily not viable, but I can’t see that happening for this particular issue at all.

10

Was the action point from the TAG to take it up immediately? No. It was to backlog it.

Ergo: there are bigger fish to fry.

11

There is no step in the process to “take it up immediately”.

Every enhancement/feature that the TAG votes on ends up in the backlog or gets rejected.

12

Surely at some point you’re not just sitting around shuffling papers, and are actually deciding what goes into the next milestone? Is this not what you’re reporting on here?

I would have thought everything back-logs automatically (without the need for discussion in a meeting, or minuting), and the meetings - in part - decide what gets taken from back-log and you go “yes do it”, or “not yet”. And it was this process you are minuting for us (and in this case it was “not yet”)?

Or is what you’re minuting here the exercise of going over all the new tickets that have been raised since the last meeting (or whenever), and doing the initial winnowing, and then there’s a separate discussion later when getting a release target organised? I guess perhaps its this you’re reporting back on?

13

I think the current workflow needs to be published and explained. There’s a flowchart, but it seems to be stuck in a thread that’s tag-private. I’ll see that we move that into a new public thread.

14

Cheers fella.

Obviously it’s no biggy, but would spare some of my propensity for quibbling semantics :wink:

(*) some of it.