Arguments against .lucee extension

[ryanguill]

I would like to argue two points. First that a new extension should not be
created, and second, if it is created it should not be called “.lucee”.

I have just read through the group and all of the arguments that I could
find for a new extension to separate the way code is processed are because
of the following needs: deprecation of existing code features and idioms,
addition of new features and idioms that would not be backwards compatible,
and a way to break away from the stigma of CFML.

Deprecation can happen inside of the existing cfml files without the need
for a new extension. Deprecation of tags, functions or idioms can be
handled at the engine level in many ways - the easiest I can see would be a
pragma rule in Application.cfc that sets a language level. Something
similiar to “use strict” in javascript. Any CFML engine (such as ACF) that
does not implement these pragmas can just ignore it. Any use of deprecated
functionality or idioms can start throwing errors if the pragma is used.
If necessary, the pragmas could have levels of enforcement, for instance
to throw a warning into a log file instead of an exception at a certain
level.

New features that are not backward compatible could be handled with the
same sort of pragma rule. The way var works in a block vs function scoping
for instance - at a certain pragma level it can have the new implementation.

Again, a pragma is just one way - using “this.” settings is another, or a
specific file that would sit alongside Application.cfc. I’m sure there are
others we could come up with.

Breaking away from the stigma and baggage of CFML is a valid concern, but I
would like to argue that the likelihood of lucee appealing to a wider
audience outside of the current CFML community is low. There are just too
many options for other languages on the JVM alone, languages that have been
designed from the ground up with a consistent vision and with modern
features. Also, unless the intention for “lucee.next” is to start an
entirely new language from scratch, you are still going to be taking at
least some of CFML’s baggage with you regardless. Calling it a new name in
hopes to trick some newcomer that lucee isn’t the CFML they’ve heard about
isn’t going to work for very long. IMO the best way to appeal to a broader
demographic is to expand the interoperability with other languages - both
using those languages inside of CFML and using CFML inside of other
languages. See the work Sean is doing with cfmljure. Using CFML as a
templating language from groovy would have a lot of appeal I believe.
Being able to use JS via Nashorn in lucee would be amazing. I know there
has been some talk about JSR-223 in the past which is a step in the right
direction - the ability to use those other languages inside of CFML would
be just a nice.

That said, if you find that it is necessary to have a new extension, please
reconsider using “.lucee” specifically. Firstly it makes compatible forks
and language implementations harder if not impossible. Consider if this
idea had come up a few years ago and “.railo” had been used. When it was
forked and became Lucee we would have been in the same boat that we have
been in with the .ra files, only it would be a much worse situation. I’m
sure its hard to consider that Lucee might be forked by the same crew
again, but surely it cannot be ruled out completely? The same would also
apply to anyone else wanting to come along and fork lucee into a compatible
engine.

It also means that Adobe cannot / will not be able to implement the
advances made. No matter what your opinion of Adobe and their handling of
the language, they have implemented features initially developed in Railo
and there is no reason to believe they wouldn’t continue to do so. And
even if you think that Lucee should forge its own path away from ACF, that
doesn’t mean that we should preclude them from being able to take up these
features, and make a compatible engine going forward. Using “.lucee” means
that at best they will implement the same features with a different
extension. This will also make things harder on library authors hoping to
support multiple engines, something that is at least possible today. Using
“.lucee” will ultimately lead to a lack of choices for developers. We
already have a documentation problem in all engines. In the past week
alone I have used the ACF documentation for lucee code many times. I have
used railo documentation in the past for ACF code because of holes they
have. Ultimately if you at least consider that the CFML history is not
something that we will be able to shake completely, we are a stronger
community together than we are individually. Of course Adobe might not
pick up any of the advances made here - but I just don’t see any good
reason for making it harder for them to do so.

There are other options available if a new extension is necessary. “.cfs”
for cfscript or “.cfn” for CF-next. I’m certain that if necessary there are
other - more inclusive - options available. In an ideal world we could get
to a broader language specification and the file extension could reflect
the version of that language, but of course I don’t believe that to happen
anytime soon.

[Adam_Cameron1]

I’m just not personally comfortable with my efforts being perceived as
my saying “Do things my way or i’m taking my toys and going home” which is
the way I feel like some of this comes across.

You don’t come across that way at all mate.

And, in case this somehow got lost in translation… all of this is
solely my opinion and I have no expectation for everyone (or even anyone)
to agree with me, or to action anything, or to do anything with this info
at all other than to note “oh, OK, that’s Cameron’s opinion”. I also
reserve the right to adjust my opinion in part or entirely as more
information comes to hand. It’s bloody stupid I feel I need to say that,
btw.

Would you say that is your 2 cents then?

Well yes: precisely. Hence my revulsion at the thought I felt I needed to
say it.On Tuesday, 10 March 2015 17:48:16 UTC, Ryan Guill wrote:

–
Adam

[ryanguill]

I started using the word “dialect” when discussing .lucee (as opposed to
.cfm / .cfc) stuff because ppl were getting uppity about being “left
behind” and CFML being marginalised.

But in reality, if whatever this .lucee concept is isn’t basically a new
language, it’ll be a waste of everyone’s time. IMO. We don’t need
CFML-and-a-half. No-one does. But if the Lucee Association wants to deliver
both a CFML solution and a [new language of their invention because they
think they can make a go of that, good on them]. I’ll help & support them.
If it’s CFML-and-a-half… I’m out.

There’s no prob with it being inspired by CFML (as you say, Jesse: C →
C++, or C++ → C# etc), but it actually has to be something in and of
itself. Not just a coupla incompatible things bolted onto CFML. That would
bite.

This is why its important to get a roadmap and clear direction from lucee
about what we are even talking about here. I don’t like how this sounds as
an ultimatum - i’m just some guy on the internet, I don’t necessarily want
lucee to change to fit me, I want lucee to make its intentions clear so I
can make decisions - but I have pretty much the exact opposite of your
opinion Adam. If this new dialect is somethings radically new i’m not
interested. There are far too many other and better options out there to
invest in. And I assert that a new language isn’t going to appeal to the
one opportunity for growth that exists for lucee today - existing CFML devs.

I feel like i’m missing some nuance to your position though Adam. Earlier
in your thread you said:

I think Lucee needs to pull its head in on this one. Whilst CFML has some

bad press, at least it has some press (*). I don’t think Lucee has the
resources (or, to be brutally honest, the ability) to market a new language
contender in such a way as the new project will me more successful than
simply marketing it as a better CFML engine than Mother Ship’s. Perhaps
with the new dialect they should be marketing it as CFML++ (not actually in
those terms literally), rather than starting from scratch.

I have plenty of opinions, plenty of which seem to be at odds with the
majority here, and thats great - im just part of some groups personally and
professionally that are trying to make long term decisions - so whatever
the decisions are we would just like to know what to expect.

[ryanguill]

I think the issue for me is less how this sort of thing is handled - it’s
all doable as you say - but I am hesitant about the divergence from Adobe
all within the same language.

That is a fair position to take, but to be clear - my argument is not
against diverging from ACF or CFML’s history - it is against using a file
extension as the gate to those changes. I am for the deprecation and new
features in general (I reserve the right to be against any of them
specifically).

Breaking away from the stigma and baggage of CFML is a valid concern

I think Lucee needs to pull its head in on this one. Whilst CFML has some
bad press, at least it has some press (*). I don’t think Lucee has the
resources (or, to be brutally honest, the ability) to market a new language
contender in such a way as the new project will me more successful than
simply marketing it as a better CFML engine than Mother Ship’s. Perhaps
with the new dialect they should be marketing it as CFML++ (not actually in
those terms literally), rather than starting from scratch.

I agree. My opinion is that the best chances in the future is lucee
marketed as a better, more evolved CFML.

There are other options available if a new extension is necessary.
“.cfs” for cfscript or “.cfn” f

Well: neither of those actually are available though:
http://filext.com/file-extension/cfn
http://filext.com/file-extension/cfs

We would hardly be the first to use the same extension as some other
filename. Rust uses .rs which is also
taken: http://filext.com/file-extension/rs. Ruby’s .rb files are the same
extension as real basic files.

But yes, those were just examples, I don’t particularly like either one of
them.

[Adam_Cameron1]

This is why its important to get a roadmap and clear direction from lucee
about what we are even talking about here. I don’t like how this sounds as
an ultimatum - i’m just some guy on the internet, I don’t necessarily want
lucee to change to fit me, I want lucee to make its intentions clear so I
can make decisions - but I have pretty much the exact opposite of your
opinion Adam.

Which is fine. You don’t, btw, have to apologise for being “just some
person”. We all are. All any of us are doing is expressing an opinion. This
is why mailing lists exist.

If this new dialect is somethings radically new i’m not interested.
There are far too many other and better options out there to invest in.
And I assert that a new language isn’t going to appeal to the one
opportunity for growth that exists for lucee today - existing CFML devs.

Cool. You seem to be frightened to not agree with people, Ryan. It’s fine.
I think hyour opinions are well-formed and worth everyone reading and
giving consideration to. I can do all this whilst not actually necessarily
agreeing with them. So oght everyone else be able to, I reckon (I have no
reason to doubt this).

I feel like i’m missing some nuance to your position though Adam. Earlier
in your thread you said:

I think Lucee needs to pull its head in on this one. Whilst CFML has some

bad press, at least it has some press (*). I don’t think Lucee has the
resources (or, to be brutally honest, the ability) to market a new language
contender in such a way as the new project will me more successful than
simply marketing it as a better CFML engine than Mother Ship’s. Perhaps
with the new dialect they should be marketing it as CFML++ (not actually in
those terms literally), rather than starting from scratch.

I have plenty of opinions, plenty of which seem to be at odds with the
majority here, and thats great - im just part of some groups personally and
professionally that are trying to make long term decisions - so whatever
the decisions are we would just like to know what to expect.

You’re conflating (at least) two things. Lucee is actively shying away from
an association with CFML. People have observed that its roots were very
downplayed in the first pass of the marketing website. There were a few
“cautious” comments from posters here who noticed this initially.

Previously I was all good with them distancing themselves from CFML, and I
see where they were coming from. However they’ve distanced themselves from
CFML, and then replaced that with… nothing. That’s daft. If they don’t
want to mention CFML, they have to then replace that with something better.
As they haven’t achieved that, I suspect they don’t have any further idea
on the subject, therefore I think the idea to distance themselves from CFML

• whilst admirable - was a mistake.

As for whether I think they should do the .lucee dialect or not? Well I
think… no. No they shouldn’t. I used to think they should, but I don’t
think they should any more. I don’t think they’ve got the personnel to
achieve what they need to achieve here. So they ought to instead focus on
delivering a performant, low-footprint CFML engine. This is playing to
their strengths.

However they’re going to do it, we all know this, so my position there is
“in for a penny, in for a pound” (or as is actually going through my head
“piss or get off the pot”). CFML-and-a-half is a waste of time for what I
think they ought to be wanting to do. Whether or not I think they should
be doing it at all.

And, in case this somehow got lost in translation… all of this is solely
my opinion and I have no expectation for everyone (or even anyone) to agree
with me, or to action anything, or to do anything with this info at all
other than to note “oh, OK, that’s Cameron’s opinion”. I also reserve the
right to adjust my opinion in part or entirely as more information comes to
hand. It’s bloody stupid I feel I need to say that, btw.On Tuesday, 10 March 2015 16:58:22 UTC, Ryan Guill wrote:

–
Adam

[ryanguill]

Which is fine. You don’t, btw, have to apologise for being “just some
person”. We all are. All any of us are doing is expressing an opinion. This
is why mailing lists exist.

Cool. You seem to be frightened to not agree with people, Ryan. It’s fine.
I think hyour opinions are well-formed and worth everyone reading and
giving consideration to. I can do all this whilst not actually necessarily
agreeing with them. So oght everyone else be able to, I reckon (I have no
reason to doubt this).

I am not worried about not agreeing with people, it’s why I started the
thread after all. I’m just not personally comfortable with my efforts
being perceived as my saying “Do things my way or i’m taking my toys and
going home” which is the way I feel like some of this comes across. I want
to offer my opinions and let the powers that be decide - and I want them to
make those decisions without some veiled threat influencing them. I hope
that decisions will be made on practical, reasoned and researched
information, not the perception from the outspoken few that are brave
enough to step up in the discussions. But ultimately I just hope to spur
some decision.

And, in case this somehow got lost in translation… all of this is solely
my opinion and I have no expectation for everyone (or even anyone) to agree
with me, or to action anything, or to do anything with this info at all
other than to note “oh, OK, that’s Cameron’s opinion”. I also reserve the
right to adjust my opinion in part or entirely as more information comes to
hand. It’s bloody stupid I feel I need to say that, btw.

Would you say that is your 2 cents then?

[dajester2013]

Well said, Ryan. I am torn on the issue also, mostly for the point you
made about the market being too saturated with JVM languages. However, I
keep coming back to the thought of how far can you go, really, in defining
a new dialect before it becomes a new language? And shouldn’t a new
language have its own extension?

Something that comes to my mind is when C was extended and became C++, the
.cpp file extension was introduced to prevent confusion even though it
wasn’t really a new language, just a superset of features. And even then,
older .c files were allowed to be compiled and included right along side
.cpp files as C++ is C. I see this as exactly what is being suggested
for Lucee - which sounds great to me.

Gert also has a very valid point:

… let’s not forget that the extension cfm contains the name ColdFusion
in it as well …

It was only later that a distinction was drawn between ColdFusion the
Engine and ColdFusion the Language (more specifically, ColdFusion Markup,
the Language). The same sort of distinction would need to be made for
Lucee the Engine vs Lucee the (Dialect/Language/whatever).

Overall, I think that a new file extension (and .lucee was only one
suggestion - I would prefer something along the lines of .lc, or .luc, or
.lcm/.lcc, or .lcs) offers the clearest distinction as to what code the
file actually contains. Adding pragma means as a developer, it becomes
harder to look at a particular section of code and determine what rules are
being applied. It also means I cannot look at various packages of code and
know immediately which ones work on ACF/Railo/Lucee, and the those that
work exclusively on Lucee.

[Abram_Adams]

Good points all around. I’m in the camp that a “CFML-and-a-half” is
exactly what Lucee should be. Well, maybe a-better-CFML-and-a-half.

Most language splits I’ve witnessed over the years end up with way too many
folks on both sides of the split for way too long. This is because they’ve
always been an all-or-nothing switch. One of the upcoming “splits” is
Angular 1.x to Angular 2.x. Breaking changes abound. However, what the
google team is doing is providing a way to trickle in the new stuff as you
go. You can use 2.x controllers, components/directives, etc… against
your existing 1.x stuff (and the other way) and just convert as time
allows. So those that are invested in Angular 1.x or rely on external
dependencies don’t have to start completely over to adopt 2.x. I think
goolge employs some pretty smart people, and if that is what they’ve banked
on to bridge the gap I think it’s worth considering for cfml in lucee.

I personally don’t care if there is a new extension, or if it’s named .lsd
or .imnotnoreverwascoldfusionsodontevengoogleit_plz. If you’re doing it
right your dev team will be the only ones that have to look at it. To me
the important part is that both cfml and lucee-script (because lucee should
NOT have it’s own markup) should be able to coexist on the same server and
in the same context. Why not support all the lucee goodies in a cfc with
“use strict” or whatnot (as others have suggested) and in a new extension
if someone wants to use it without the “use strict”? Shouldn’t be that
hard, right?

To echo others that have said it already (and to repeat myself), we really
need some sort of roadmap. Without it we’re just driving, wasting fuel,
getting nowhere.

[Adam_Cameron1]

Excellent post, Ryan!

I would like to argue two points. First that a new extension should not
be created,

I’m heading in this direction too. I am severely doubting there’s a place
for it in the market, and it could ever get sufficient traction to be
anything other a dilution of Lucee’s - very scarce - dev resources.

But equally I think ppl have had some good ideas that aren’t compatible
with CFML: either in the sense of Adobe’s “reference” version, or just the
language the way it is, even ignoring the Adobe side of things, so not sure
what to do about that.

and second, if it is created it should not be called “.lucee”.

This had not occurred to me, and you go on to make a very good case. So if
the Lucee Association did decide to go with a new language, the language’s
name short be divorced from the vendor producing it? Makes good sense, for
the reasons you cite.

Deprecation
New features

I think the issue for me is less how this sort of thing is handled - it’s
all doable as you say - but I am hesitant about the divergence from Adobe
all within the same language.

Breaking away from the stigma and baggage of CFML is a valid concern

I think Lucee needs to pull its head in on this one. Whilst CFML has some
bad press, at least it has some press (*). I don’t think Lucee has the
resources (or, to be brutally honest, the ability) to market a new language
contender in such a way as the new project will me more successful than
simply marketing it as a better CFML engine than Mother Ship’s. Perhaps
with the new dialect they should be marketing it as CFML++ (not actually in
those terms literally), rather than starting from scratch.

There are other options available if a new extension is necessary. “.cfs”
for cfscript or “.cfn” f

Well: neither of those actually are available though:

CFN File Extension - What is it? How to open a CFN file?

CFS File Extension - What is it? How to open a CFS file?

But still, yes - detail aside - I think you’re right.

I was initially very enthused by the exciting shiny new direction that the
Lucee Association could take us. But as the dust settles after the launch,
I don’t see it as being viable any more to be too excited about stuff. I
think they need to retrench and re-message. Embrace that what they are is a
CFML variant, work on converting and growing the existing CFML base instead
of trying to invent another one, and accept that what they do is CFML. Just
do a better job of it than Adobe does (and perhaps have a bit more
aspiration than that. That’s just daming with faint praise

That said, I also think the dust is still settling after launch so I am
still watching with - slightly muted now - enthusiasm - but I’ve reigned my
expectations back in a bit too.

What I’d like to see from Lucee is this:

• some sort of indication of a roadmap of where they intend to take the
  project as a whole. Not a technical roadmap (no mention of functions or
  tags or file extensions), but a marketing one. How are they planning on
  improving its install / usage base.
• a more coherent plan of what the story is with the new dialect. I am
  concerned there’s gonna be a half-baked jump into the unknown here, rather
  than something well planned and considered before they start.

There needs to be more to this project than Micha and Igal pushing releases
out. I’m hoping someone else is behind the scenes doing some actual
business planning of all this. It’s lack of this stuff that has me most
concerned @ the mo’.On Tuesday, 10 March 2015 00:36:35 UTC, Ryan Guill wrote:

–
Adam

(*) as far as I know there’s still not even an official press release
stating Lucee exists. My blog article is about as close to that as we’ve
got, and my blog doesn’t have appropriate credibility for that to be a
valid approach.

[Robert_Munn]

Don’t take my word for it, because I don’t represent LAS, but from what I have gleaned from the discussions, the current plan seems to be:

• Lucee on the market ( done )
• Get the CFML community informed about and interested in Lucee ( ongoing )
• Installers, docs, wiki for Lucee on the market ( ongoing )
• Design new language / dialect for Lucee ( ongoing, and note from the spreadsheet of features that there has been a lot of discussion behind the scenes about it )
• Lucee 5.0.0
  • new dialect
  • extension packs for non-core parts of CFML (ORM, etc. )
  • other ( ? )

I don’t think there is any reason to debate the new dialect. If the members of LAS want a new dialect, Lucee will include it. CFML will still be supported, so it really isn’t an issue to be concerned with, IMHO.

Beyond these features, there is a whole world of features future versions of Lucee could include. I would like Nashorn integration, others might like Clojure integration, etc. Whether they are included is up to the members of LAS.On Mar 10, 2015, at 9:58 AM, Ryan Guill <@Ryan_Guill> wrote:

This is why its important to get a roadmap and clear direction from lucee about what we are even talking about here. I don’t like how this sounds as an ultimatum - i’m just some guy on the internet, I don’t necessarily want lucee to change to fit me, I want lucee to make its intentions clear so I can make decisions - but I have pretty much the exact opposite of your opinion Adam. If this new dialect is somethings radically new i’m not interested. There are far too many other and better options out there to invest in. And I assert that a new language isn’t going to appeal to the one opportunity for growth that exists for lucee today - existing CFML devs.

[Dominic_Watson]

I agree, and think it would be great to have a discussion around the topic,
“What can Lucee do to break free from CFML compatibility, while still
supporting the CFML community?”. A new language set, controlled by a
different extension is certainly one way - but I wonder if the community
has any other ideas (rather than debating the wrong question of “Should we
have a .lucee extension?”).

What I think may muddy matters here is that there is already code to make
this new extension work, it just has not yet been added to the Lucee core.
So there is already personal investment in this for those involved. I for
one would urge Lucee to be cautious of moving into core too early.On 10 March 2015 at 07:14, Adam Cameron <@Adam_Cameron1> wrote:

Excellent post, Ryan!

On Tuesday, 10 March 2015 00:36:35 UTC, Ryan Guill wrote:

I would like to argue two points. First that a new extension should not
be created,

I’m heading in this direction too. I am severely doubting there’s a place
for it in the market, and it could ever get sufficient traction to be
anything other a dilution of Lucee’s - very scarce - dev resources.

But equally I think ppl have had some good ideas that aren’t compatible
with CFML: either in the sense of Adobe’s “reference” version, or just the
language the way it is, even ignoring the Adobe side of things, so not sure
what to do about that.

and second, if it is created it should not be called “.lucee”.

This had not occurred to me, and you go on to make a very good case. So if
the Lucee Association did decide to go with a new language, the language’s
name short be divorced from the vendor producing it? Makes good sense, for
the reasons you cite.

Deprecation
New features

I think the issue for me is less how this sort of thing is handled - it’s
all doable as you say - but I am hesitant about the divergence from Adobe
all within the same language.

Breaking away from the stigma and baggage of CFML is a valid concern

I think Lucee needs to pull its head in on this one. Whilst CFML has some
bad press, at least it has some press (*). I don’t think Lucee has the
resources (or, to be brutally honest, the ability) to market a new language
contender in such a way as the new project will me more successful than
simply marketing it as a better CFML engine than Mother Ship’s. Perhaps
with the new dialect they should be marketing it as CFML++ (not actually in
those terms literally), rather than starting from scratch.

There are other options available if a new extension is necessary.
“.cfs” for cfscript or “.cfn” f

Well: neither of those actually are available though:
http://filext.com/file-extension/cfn
http://filext.com/file-extension/cfs

But still, yes - detail aside - I think you’re right.

I was initially very enthused by the exciting shiny new direction that the
Lucee Association could take us. But as the dust settles after the launch,
I don’t see it as being viable any more to be too excited about stuff. I
think they need to retrench and re-message. Embrace that what they are is a
CFML variant, work on converting and growing the existing CFML base instead
of trying to invent another one, and accept that what they do is CFML. Just
do a better job of it than Adobe does (and perhaps have a bit more
aspiration than that. That’s just daming with faint praise

That said, I also think the dust is still settling after launch so I am
still watching with - slightly muted now - enthusiasm - but I’ve reigned my
expectations back in a bit too.

What I’d like to see from Lucee is this:

• some sort of indication of a roadmap of where they intend to take the
  project as a whole. Not a technical roadmap (no mention of functions or
  tags or file extensions), but a marketing one. How are they planning on
  improving its install / usage base.
• a more coherent plan of what the story is with the new dialect. I am
  concerned there’s gonna be a half-baked jump into the unknown here, rather
  than something well planned and considered before they start.

There needs to be more to this project than Micha and Igal pushing
releases out. I’m hoping someone else is behind the scenes doing some
actual business planning of all this. It’s lack of this stuff that has me
most concerned @ the mo’.

–
Adam

(*) as far as I know there’s still not even an official press release
stating Lucee exists. My blog article is about as close to that as we’ve
got, and my blog doesn’t have appropriate credibility for that to be a
valid approach.

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/c5fcc7bf-c7ee-49f0-99c9-8c86855abd2d%40googlegroups.com
https://groups.google.com/d/msgid/lucee/c5fcc7bf-c7ee-49f0-99c9-8c86855abd2d%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

–
Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn
http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB

[Adam_Cameron1]

Well said, Ryan. I am torn on the issue also, mostly for the point you
made about the market being too saturated with JVM languages. However, I
keep coming back to the thought of how far can you go, really, in defining
a new dialect before it becomes a new language? And shouldn’t a new
language have its own extension?

I started using the word “dialect” when discussing .lucee (as opposed to
.cfm / .cfc) stuff because ppl were getting uppity about being “left
behind” and CFML being marginalised.

But in reality, if whatever this .lucee concept is isn’t basically a new
language, it’ll be a waste of everyone’s time. IMO. We don’t need
CFML-and-a-half. No-one does. But if the Lucee Association wants to deliver
both a CFML solution and a [new language of their invention because they
think they can make a go of that, good on them]. I’ll help & support them.
If it’s CFML-and-a-half… I’m out.

There’s no prob with it being inspired by CFML (as you say, Jesse: C →
C++, or C++ → C# etc), but it actually has to be something in and of
itself. Not just a coupla incompatible things bolted onto CFML. That would
bite.On Tuesday, 10 March 2015 15:53:15 UTC, Jesse Shaffer wrote:

–
Adam

[Adam_Cameron1]

07:34:20 UTC, Micha wrote:

so it is all about controlling the runtime and compiler behaviour on
template level.

07:53:30 UTC, Micha wrote:

I forget to say that this would also include a rethinking of all functions
and tags …

[exasperation]

I think I’m going to try to ignore all discussions about .lucee until you
work out what it’s all about, and provide us with a coherent plan/roadmap.–
Adam

[Adam_Cameron1]

So the idea of this extension is not to do a new language, it is to have a
different way to control this existing settings on template level.

so it is all about controlling the runtime and compiler behaviour on
template level.

If *that *is the rationale then I think .lucee is a poor approach to
solving the issue at hand. .lucee compared to .cfm implies a far greater
departure than just some compiler settings. You should probably be
positioning it as .cfm2 or something like that.

Or explore Ryan’s pragma solution more, as I think that’s perhaps a better
fit for what you’re trying to achieve.On Wednesday, 11 March 2015 07:34:20 UTC, Micha wrote:

–
Adam

[ddspringle]

The CFML community… dragging developers kicking and screaming into modern
development practices since 2003. Emphasis on the kicking and screaming
part.

I favor a ‘radical new language’ from Lucee. Preferably one that allows
developers of any other modern language to use it effectively. The idea
that there’s too much stiff competition to do so I disagree with. If that
were the case, there would be no competition at all - we’d all still be
writing QWBASIC.

I also favor ditching the CFML baggage whilst also being an effective,
lightweight and uber fast CFML engine. Direct replacement for and
compatibility with ACF should no longer be a primary consideration. Sorry,
but breaking changes are how languages evolve, and CFML needs to evolve.

Doing some of the ‘use strict’ type of stuff may help to lead CFML
developers towards the ‘radical new language’ over time, as having both
syntax gives developers the ability to take advantage of new language
features while remaining comfortable with their currently acquired CFML
knowledge. Learning the differences would be no more difficult than
learning new features when they’re added to ACF. And, if it is for someone,
then they can just use ACF and avoid using Lucee. We shouldn’t hold back
the language for those that cannot (or will not) move forward with it.

My 2 cents on the matter.

Having added my 2 cents, I’d also like to state that while we can all
eagerly express our opinions on the topic - nothing ever gets done when
decided by committee. I’ve seen good projects and ideas go way, way south
in the muck and mire of opinion. Any excitement once shared rapidly
dissolved by the back and forth disagreement among CFML developers. We’re
not politicians… we need to work towards a compromise of opinions and
support LAS in their efforts to provide us with the rich opportunity to
provide input… but we need to be focusing on providing positive input. We
need consensus, which will only ever come through compromise. Everyone has
valid concerns and opinions - now… where is the middle ground we can all
live with?

– Denny

[micstriit]

it is not only about compiler settings, most settings are runtime settings!
I forget to say that this would also include a rethinking of all functions
and tags …

MichaOn Wed, Mar 11, 2015 at 8:49 AM, Adam Cameron <@Adam_Cameron1> wrote:

On Wednesday, 11 March 2015 07:34:20 UTC, Micha wrote:

So the idea of this extension is not to do a new language, it is to have
a different way to control this existing settings on template level.

so it is all about controlling the runtime and compiler behaviour on
template level.

If *that *is the rationale then I think .lucee is a poor approach to
solving the issue at hand. .lucee compared to .cfm implies a far greater
departure than just some compiler settings. You should probably be
positioning it as .cfm2 or something like that.

Or explore Ryan’s pragma solution more, as I think that’s perhaps a better
fit for what you’re trying to achieve.

–
Adam

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/f27b38e7-fcba-4b2d-9d92-7d1038e37e11%40googlegroups.com
https://groups.google.com/d/msgid/lucee/f27b38e7-fcba-4b2d-9d92-7d1038e37e11%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

[micstriit]

When I have started Railo I disagreed with a lot of behaviour in the ACF
implementation.
Some of them, we simply handled differently like for example “pass array by
value” or we did a setting in the administrator, like for example for
“scope cascading”.

But doing a setting like this in the admin, means to break compatibility
for the whole web context/server, what is simply not possible for most
users, because the relay on frameworks/applications that are ACF compatible
and because of that setting like this are not well adapted.

In a second step we introduced a lot of the admin settings in the
Application.cfc, so you can have this settings independent of what is
defined in the administrator, but the problem with breaking 3 party
frameworks/application remains.

Some of the settings are also available on code level, for example “local
scope mode”, you can define the default behaviour in the admin, in the
application.cfc and in the function itself.

But doing this in the function also produce an unnecessary “noise” in the
function!

Let me take the “local scope mode” setting as an example, I personally like
this setting a lot, in my opinion this makes scope act as they should do.
When I do testcases I cannot set this in my admin or my application.cfc
because it would break Testbox, so the only option for me is to set it
inside the function itself, what I do sometimes, but many times I simply
add a “local.” to my functions … .
Same with full null support enable, I love this feature but I never have
used it yet, because I can only do in the admin and it always breaks
existing code.

So in my personal opinion all this settings Lucee has are great in theory,
but are more or less useless in real life for most people, because you
cannot use them without breaking existing code.

That was the reason I was coming with the idea of an extension, this
extension allows me to control all this settings simply by using a
different extension, so if I do a test case, I would use the .lucee
extension and I had no troubles using all this features, even i’m using
frameworks like testbox that are realing on a different environment than my
template does.

So the idea of this extension is not to do a new language, it is to have a
different way to control this existing settings on template level.

so it is all about controlling the runtime and compiler behaviour on
template level.

MichaOn Tue, Mar 10, 2015 at 1:36 AM, Ryan Guill <@Ryan_Guill> wrote:

I would like to argue two points. First that a new extension should not
be created, and second, if it is created it should not be called “.lucee”.

I have just read through the group and all of the arguments that I could
find for a new extension to separate the way code is processed are because
of the following needs: deprecation of existing code features and idioms,
addition of new features and idioms that would not be backwards compatible,
and a way to break away from the stigma of CFML.

Deprecation can happen inside of the existing cfml files without the need
for a new extension. Deprecation of tags, functions or idioms can be
handled at the engine level in many ways - the easiest I can see would be a
pragma rule in Application.cfc that sets a language level. Something
similiar to “use strict” in javascript. Any CFML engine (such as ACF) that
does not implement these pragmas can just ignore it. Any use of deprecated
functionality or idioms can start throwing errors if the pragma is used.
If necessary, the pragmas could have levels of enforcement, for instance to
throw a warning into a log file instead of an exception at a certain level.

New features that are not backward compatible could be handled with the
same sort of pragma rule. The way var works in a block vs function scoping
for instance - at a certain pragma level it can have the new implementation.

Again, a pragma is just one way - using “this.” settings is another, or a
specific file that would sit alongside Application.cfc. I’m sure there are
others we could come up with.

Breaking away from the stigma and baggage of CFML is a valid concern, but
I would like to argue that the likelihood of lucee appealing to a wider
audience outside of the current CFML community is low. There are just too
many options for other languages on the JVM alone, languages that have been
designed from the ground up with a consistent vision and with modern
features. Also, unless the intention for “lucee.next” is to start an
entirely new language from scratch, you are still going to be taking at
least some of CFML’s baggage with you regardless. Calling it a new name in
hopes to trick some newcomer that lucee isn’t the CFML they’ve heard about
isn’t going to work for very long. IMO the best way to appeal to a broader
demographic is to expand the interoperability with other languages - both
using those languages inside of CFML and using CFML inside of other
languages. See the work Sean is doing with cfmljure. Using CFML as a
templating language from groovy would have a lot of appeal I believe.
Being able to use JS via Nashorn in lucee would be amazing. I know there
has been some talk about JSR-223 in the past which is a step in the right
direction - the ability to use those other languages inside of CFML would
be just a nice.

That said, if you find that it is necessary to have a new extension,
please reconsider using “.lucee” specifically. Firstly it makes compatible
forks and language implementations harder if not impossible. Consider if
this idea had come up a few years ago and “.railo” had been used. When it
was forked and became Lucee we would have been in the same boat that we
have been in with the .ra files, only it would be a much worse situation.
I’m sure its hard to consider that Lucee might be forked by the same crew
again, but surely it cannot be ruled out completely? The same would also
apply to anyone else wanting to come along and fork lucee into a compatible
engine.

It also means that Adobe cannot / will not be able to implement the
advances made. No matter what your opinion of Adobe and their handling of
the language, they have implemented features initially developed in Railo
and there is no reason to believe they wouldn’t continue to do so. And
even if you think that Lucee should forge its own path away from ACF, that
doesn’t mean that we should preclude them from being able to take up these
features, and make a compatible engine going forward. Using “.lucee” means
that at best they will implement the same features with a different
extension. This will also make things harder on library authors hoping to
support multiple engines, something that is at least possible today. Using
“.lucee” will ultimately lead to a lack of choices for developers. We
already have a documentation problem in all engines. In the past week
alone I have used the ACF documentation for lucee code many times. I have
used railo documentation in the past for ACF code because of holes they
have. Ultimately if you at least consider that the CFML history is not
something that we will be able to shake completely, we are a stronger
community together than we are individually. Of course Adobe might not
pick up any of the advances made here - but I just don’t see any good
reason for making it harder for them to do so.

There are other options available if a new extension is necessary. “.cfs”
for cfscript or “.cfn” for CF-next. I’m certain that if necessary there are
other - more inclusive - options available. In an ideal world we could get
to a broader language specification and the file extension could reflect
the version of that language, but of course I don’t believe that to happen
anytime soon.

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/a35d3439-828a-48cd-bc9f-3581ecc88187%40googlegroups.com
https://groups.google.com/d/msgid/lucee/a35d3439-828a-48cd-bc9f-3581ecc88187%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

[Andrew_Penhorwood]

The .lucee extension make more sense then pragma or other options presented
in my opinion. At a glance I can tell that .lucee templates will process
differently. The extension is easy to control, easy to recognize, and
gives easy to understand outcomes.

I do agree that we need a roadmap of where the Lucee Association want to
take this.

Andrew PenhorwoodOn Wednesday, March 11, 2015 at 3:49:28 AM UTC-4, Adam Cameron wrote:

On Wednesday, 11 March 2015 07:34:20 UTC, Micha wrote:

So the idea of this extension is not to do a new language, it is to have
a different way to control this existing settings on template level.

so it is all about controlling the runtime and compiler behaviour on
template level.

If *that *is the rationale then I think .lucee is a poor approach to
solving the issue at hand. .lucee compared to .cfm implies a far greater
departure than just some compiler settings. You should probably be
positioning it as .cfm2 or something like that.

Or explore Ryan’s pragma solution more, as I think that’s perhaps a better
fit for what you’re trying to achieve.

–
Adam

[Leftbower]

Micha,

OK, I am confused. First I thought a new extension was for a new language
direction, perhaps altogether new.

Then your statement above seems to indicate that a new ext. would really
just be a way to do away with all of the admin flags (i.e. perhaps files
with .lucee will all, for example, have full null support, keep struct keys
case sensitive, etc.) but otherwise be the same? (I think? Something close
to that?)

But then you chimed back in with: “I forget to say that this would also
include a rethinking of all functions and tags”. But not really any
explanation as to what that meant or why it would be needed?

So… yeah… I am totally baffled.

I get that you guys have a ton going on and appreciate the various efforts
and that you’re trying to do a whole lot in a short time to get off of the
ground, but it sure would be nice to understand what the plan is, because
as someone who’s read EVERY post on this list (and Railo’s for that matter)
… every time I think I know what you’re all on about, I then get thrown
for a loop and find I don’t know what’s what.

I don’t mind weighing in on extensions and language direction, etc. but at
this point I feel there really needs to be some more guidance from the
Lucee team because it seems to be kind of a free for all. There was talk of
a roadmap, etc. a while back… that would certainly be a step in the right
direction! Even a roadmap about the roadmap would be welcome!On Wednesday, March 11, 2015 at 12:53:30 AM UTC-7, Micha wrote:

it is not only about compiler settings, most settings are runtime settings!
I forget to say that this would also include a rethinking of all functions
and tags …

Micha

On Wed, Mar 11, 2015 at 8:49 AM, Adam Cameron <dac...@gmail.com <javascript:>> wrote:

On Wednesday, 11 March 2015 07:34:20 UTC, Micha wrote:

So the idea of this extension is not to do a new language, it is to have
a different way to control this existing settings on template level.

so it is all about controlling the runtime and compiler behaviour on
template level.

If *that *is the rationale then I think .lucee is a poor approach to
solving the issue at hand. .lucee compared to .cfm implies a far greater
departure than just some compiler settings. You should probably be
positioning it as .cfm2 or something like that.

Or explore Ryan’s pragma solution more, as I think that’s perhaps a
better fit for what you’re trying to achieve.

–
Adam

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+un...@googlegroups.com <javascript:>.
To post to this group, send email to lu...@googlegroups.com <javascript:>
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/f27b38e7-fcba-4b2d-9d92-7d1038e37e11%40googlegroups.com
https://groups.google.com/d/msgid/lucee/f27b38e7-fcba-4b2d-9d92-7d1038e37e11%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

[micstriit]

I was never speaking about a new language, I was always speaking about a
dialect on top of the engine.
The current idea is as follows.

We review all possible runtime and compiler settings and we define for
every one the default behavior for this dialect, this includes of course
also settings new to lucee 5 like “handle unquoted tag attributes as
variable|string”.
We review the core tag and function library, for example we remove the
function “dateFormat” and rename “lsDateFormat” to “dateFormat”.
The libraries also define the prefix of tags (cf) and if not existing tags
are ignored or not. So we can also control this behavior.

All I was taking about is covered by this…

MichaAm Freitag, 13. März 2015 schrieb ADK :

Micha,

OK, I am confused. First I thought a new extension was for a new language
direction, perhaps altogether new.

Then your statement above seems to indicate that a new ext. would really
just be a way to do away with all of the admin flags (i.e. perhaps files
with .lucee will all, for example, have full null support, keep struct keys
case sensitive, etc.) but otherwise be the same? (I think? Something close
to that?)

But then you chimed back in with: “I forget to say that this would also
include a rethinking of all functions and tags”. But not really any
explanation as to what that meant or why it would be needed?

So… yeah… I am totally baffled.

I get that you guys have a ton going on and appreciate the various efforts
and that you’re trying to do a whole lot in a short time to get off of the
ground, but it sure would be nice to understand what the plan is, because
as someone who’s read EVERY post on this list (and Railo’s for that matter)
… every time I think I know what you’re all on about, I then get thrown
for a loop and find I don’t know what’s what.

I don’t mind weighing in on extensions and language direction, etc. but at
this point I feel there really needs to be some more guidance from the
Lucee team because it seems to be kind of a free for all. There was talk of
a roadmap, etc. a while back… that would certainly be a step in the right
direction! Even a roadmap about the roadmap would be welcome!

On Wednesday, March 11, 2015 at 12:53:30 AM UTC-7, Micha wrote:

it is not only about compiler settings, most settings are runtime
settings!
I forget to say that this would also include a rethinking of all
functions and tags …

Micha

On Wed, Mar 11, 2015 at 8:49 AM, Adam Cameron dac...@gmail.com wrote:

On Wednesday, 11 March 2015 07:34:20 UTC, Micha wrote:

So the idea of this extension is not to do a new language, it is to
have a different way to control this existing settings on template level.

so it is all about controlling the runtime and compiler behaviour on
template level.

If *that *is the rationale then I think .lucee is a poor approach to
solving the issue at hand. .lucee compared to .cfm implies a far greater
departure than just some compiler settings. You should probably be
positioning it as .cfm2 or something like that.

Or explore Ryan’s pragma solution more, as I think that’s perhaps a
better fit for what you’re trying to achieve.

–
Adam

–
You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/lucee/f27b38e7-fcba-4b2d-9d92-7d1038e37e11%40googlegroups.com
https://groups.google.com/d/msgid/lucee/f27b38e7-fcba-4b2d-9d92-7d1038e37e11%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.
To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/0cde0e0f-e733-4bf9-a411-64efc3595e9e%40googlegroups.com
https://groups.google.com/d/msgid/lucee/0cde0e0f-e733-4bf9-a411-64efc3595e9e%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.