TAG Oct 7th Meeting Agenda/Minutes

Meeting date/time is as follows:

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

Agenda Items

  • Approve meeting minutes and votes from last meeting ( http://lang.lucee.org/t/tag-sept-16th-meeting-agenda/210 )
  • Should Lucee Lang be released as part of Lucee 5 at all / as Alpha / as Beta / as finished product?
  • How compatible should Lucee Lang be with CFML?
  • What kind of language do we think LuceeLang should be? (perhaps could be done as a TAG review of the Lucee Lang section of the Manifesto?)
  • Ticket review
  • Ad-hoc items
  • Confirm date/time of next meeting

I think to expand on ‘Lucee language planning’, I’d like to see us address the questions:

  • Should Lucee Lang be released as part of Lucee 5 at all / as Alpha / as Beta / as finished product?

  • How compatible should Lucee Lang be with CFML?

  • What kind of language do we think LuceeLang should be? (perhaps could be done as a TAG review of the Lucee Lang section of the Manifesto?)

While not formally ratified by the LAS Board I think its worth highlighting our thinking around Lucee Next Gen MVP, as decisions around resourcing this release will be finalised shortly.

While it was hoped Lucee Language might be a core part of the next major release of Lucee it will no longer form a part of that release.

With the formation of the TAG and the overall desire to have the best possible language implementation we all accept we can’t rush a release of Lucee Language. In addition, we do not want the next major release of Lucee Server to be delayed waiting for the finalisation of Lucee Language specification.

There are many awesome things in next-gen Lucee Server, not least the OSGi enabled core engine, and we are marshalling our efforts to finalise a release in a timely fashion.

That said, our current preference is to include Lucee Language in an alpha or “experimental” state that can be activated by developers wanting to play with the language. And to enable the ongoing updating of Lucee Language implementation within the core engine to assist with its evolution.

We would appreciate any advice the TAG might offer with respect to how we might best facilitate experimentation with Lucee Language, and whether it should be included as part of the Lucee Server release cycle or if we should be considering the release of a completely separate Lucee Language enabled build.

1 Like

@modius @dom_watson Thanks for the thoughts gents. I’ve added these items to our agenda and we will review Geoff’s comments as the current thoughts of the LAS management board.

Have there been meeting minutes posted anywhere? I didn’t see them on the forum. I would love to see what the current status of the Lucee language is. Are there any write ups of the new language as it currently stands?

I @awayken, I think @simonhooker will be working on getting the meeting minutes posted up today.

Sorry they’re a little late - it’s been a busy few days! Here’s the minutes from last Wednesday.

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

Summary of votes taken in this meeting

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

  • LDEV-317 JavaNew() should probably be JavaObjectNew() - Rejected following discussion, no vote deemed necessary.

Meeting minutes

  1. Approve meeting minutes from last meeting
  2. Should LuceeLang be released as part of Lucee 5 at all / as Alpha / as Beta / as finished product?
    • Discussion
      • Does LuceeLang stay as an experimental feature that can be enabled?
      • Opinion that Lucee 5 should not be released with LuceeLang, advertised as “finished”.
      • Confirmation from devs that this is currently the plan, and that it wouuld be possible to add in a switch that allows people to enable it.
      • Concerns about leaving it enabled as default due to the fact people would start using it, and that breaking changes to the code would provoke frustration / become more difficult.
      • Perhaps leave it as an “undocumented” feature, able to be enabled through XML / other config but not through the admin. Exception to be thrown if someone tries to use LuceeLang while LuceeLang disabled.
      • Concerns about what should actually be in LuceeLang.
      • Concerns about LuceeLang having received less testing than Lucee CFML. Having it disabled would ensure that any potential attack vectors would due to LuceeLang would not be exposed by default.
      • Leaving a route to enable LuceeLang in Lucee 5 would allow interested users to test LuceeLang and to try it out.
      • There’s a lot of good stuff in Lucee 5 such as OSGI, no need to dilute the message with the “experimental” features.
    • Conclusion
      • LuceeLang to ship with Lucee 5 but disabled by default, no trace.
      • LuceeLang to be able to be enabled through XML / other config routes, but no option to enable it exposed in the admin
      • LuceeLang to be a hidden undocumented feature in the intial Lucee 5 release.
  3. How compatibile should LuceeLang be with CFML?
    • http://lang.lucee.org/t/luceelang-how-compatible-with-cfml-should-it-be/228/
    • Discussion
      • There should be no expectation that you can just change the extension and expect it to run.
      • Some concern expressed about compatibility for existing applications.
      • This concern met with the argument that this is not a concern as Lucee still has CFML compatibility independant of LuceeLang. Nothing stops an author from porting a CFML project to LuceeLang, but this should not be a major concern when it comes to making decisions in LuceeLang.
      • This discussion quickly moved on to the next point
  4. What kind of language do we think LuceeLang should be?
    • http://lang.lucee.org/t/luceelang-what-kind-of-language-should-it-be/229
    • Discussion
      • Indications from the “Forum polls? You bet” thread that there is a preference for OOP and member functions over top level functions.
      • Adam Camerons spreadsheet breaking down the top level functions referenced https://docs.google.com/spreadsheets/d/1mqiaJRVgh26ljEKgvhb6yf7l6uCKmAmZlIcQqlzh1KM/edit
      • Where is the benefit in changing from a top level function to a member function?
      • Language perception - to be seen as a modern scripting language then we need to think about what looks like a good language.
      • If trying to bring CFML developers that’s different to trying to bring in new developers.
      • Multiple ways of doing the same thing is not always as good as having just 1 way of doing things - presents a good way to slim down documentation and the language.
      • Some functions are type-independent
      • Suggestion for removing the top level functions from LuceeLang (not CFML mode) where the member functions already exist
      • Important to be consistent
      • Concern raised about performance implications. Response to this concern was that performance should not drive language decisions. The language should be designed and then be made to perform well.
      • CFML currently untyped so a single variable can become multiple types in its life. Iif LuceeLang remains typeless then that can make member functions more difficult, potentially problematic.
      • Optional typing mentioned as something that should be discussed in the future.
      • Lucee currently automatically performs conversions behind the scenes to convert types of arguments to match the required types for the function. For example strings that can be used in number or string functions without explicit type conversion.
      • Is this a real world concern or a theoretical concern?
      • This is more of an implementation issue than a specification issue, something to keep in mind for implementation.
      • We should be looking at this from the point of view of what we want the language to be, and then address implementation concerns as and when they arise.
      • Javascript / ECMAScript could be a good model
      • No need to create new objects for the sake of it where a new object is not required.
      • Desire to not require importing expressed, along with concerns against auto-imports.
        • Action Brad Wood to write about what he has done in ColdBox to overcome the difficulties of writing packages without a language-wide convention.
  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-317 JavaNew() should probably be JavaObjectNew()
      • Discussion
        • Lack of support for JavaObjectNew due to it being too verbose
        • Agreement that JavaNew isn’t quite right
        • new cfcName expressed as desirable but there is no equivilant for Java objects.
        • Removing JavaNew would remove some functionality relating to loading by bundle name and bundle version. This functionality is not available in CreateObject( ‘java’ ) due to the fact that CreateObject is already too complicated.
        • Finding a correct name is hard, is it the wrong thing to do?
        • Problem with adding this logic to CreateObject is that CreateObject depends on the first argument and following arguments depend on that argument due to how overloaded it is.
        • Adding a new case for Java bundle names and versions would add even more complexity to CreateObject and so confusing the existing logic and existing documentation.
        • Option to leave it in but undocumented raised, but preference to try and merge it into CreateObject preferred removing the contentious ObjectNew() and JavaNew() functions. The addition of this logic should be documented along with the removal of ObjectNew() and JavaNew().
      • Conclusion
        • Rejected due to the word “Object” adding no value to the function name.
        • JavaNew() and ObjectNew() to be removed from the CFML dialect.
  6. Date of next meeting October 28th 2015, time TBC
1 Like

Well done you lot. That sounds like a productive and… um… “thoughtful” meeting.

Keep up the good work.