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.
@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?
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.
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.
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
What kind of language do we think LuceeLang should be?
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.
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.