Is it .lc or .lucee?

language
1

As far as I can tell, all the talk of a file extension has favored .lucee but in the dev.Objective() general session slides from Geoff’s presentation, I saw .lc as the file extension.

Has a decision been formally made?

Can we get confirmation from LAS on what the LuceeLang file extension will be, at this point?

I ask primarily because I want to include LuceeLang support in FW/1 3.5 and I can’t do that until I know for sure which file extension will be used!

Thank you!

2

I will chase a definitive answer what would your preference be and why?

3

Micha prefers .lucee, I prefer .lc :smile:

The LAS consensus was a preference for either the long form .lucee and/or short form of .lc. It seems likely that both extensions will be supported, much like .html and .htm. However, I believe that there will be no distinction between templates and components/classes as there is in CFML (ie. .cfm and .cfc).

4

It seems that people have different opinions re a bunch of things in LuceeLang and that’s fine.

I’m however not a fan of ambiguity and the theory of “making everyone happy” - would it be too much to ask to just make a decision on something simple as the file suffix and choose exactly one?

1 Like
5

I agree with Kai. There’s a difference between opinionated vs. flexible in a language… but I would couch this distinction as ambiguous, rather than flexible, and for no apparently good reason that I can fathom.

6

I have a mild preference for the long form (.lucee) but don’t really care.

I’d rather make the FW/1 changes only once, however :smile:

1 Like
7

Naming is hard. It’s not too much to ask. A decision will be made.

For the record there is nothing ambiguous about a list of acceptable extensions. Nor is there anything unusual about it. I would prefer a single short extension, but i’m not sure how it matters if there ends up being two.

8

My preference would be .lucee too (.lc reminds me too much of “Livecycle”), but I don’t care either way as long at it’s one thing that everyone sticks with and LuceeLang doesn’t provide secret built-in support for the other option because it’s just so easy to do and because we can.

9

I think it is safe to assume that Lucee will run in environments that are
not restricted to 8.3 file names, so I would suggest .lucee to avoid
clashes and make it very clear what the file is without having to search
file extensions.

But, has lucee been decided upon as the name for the new dialect/language?
Could it be iris that runs on Lucee Server, supported by LAS??

I am assuming the new language will be open and other Vendors may choose to
support it as well. To I courage this, I think iris, for example, on
openBD, for example, would be a more appreciated option.

10

Given that OpenBD has kinda gone off in its own direction for the last several years – having abandoned CFML compatibility years go – I can’t imagine them being interested in supported another dialect.

I recently went back on their mailing list (its very low traffic) so I’d have a way to discuss issues I’m encountering around getting FW/1 to run on OpenBD (every few years I decide to take another run at this!). Their implementation of CFML is a long way from being compatible with ACF, Railo, or Lucee right now.

11

Like most here I prefer .lucee but I don’t have a strong opinion about it.

12

I’m not suggesting this conversation oughtn’t take place, but haven’t we gone around the houses on this already? We talked about .lucee, .lc, .luc and a coupla other options too.

I’m somewhat surprised even something like this hasn’t reached a consensus yet.

FWIW: I think .lucee. Why abbrev. something if one doesn’t need to?

–
Adam

13

Agreed.

If there was more than one, I’d like to know the rationale.

The .html / .htm parallel doesn’t wash because .htm only exists to cater for now-irrelevant file systems which had three-char limits on their file extensions. If it wasn’t for that restriction, there would never have been two different file extensions.

Same as with .cfm / .cfml, with the former seeming to win-out because “back in the day” CFML mostly ran on Winders.

–
Adam

14

I don’t know that this really qualifies as a “naming exercise”, TBH. You’e got the name, you just can’t agree whether to abbrev. it or not.

For my part which one is decided on is neither here nor there. The bigger concern is that you lot can’t seem to agree on something as inconsequential as this, and it also seems that your approach to solving it is simply to not agree, but to accommodate both camps. I think this is a pretty poor, quality-diluted approach to take.

Suggested alternative process:

  1. each party with an opinion documents and presents their case. Both pros and cons. A position without cons would be deemed incomplete, and not considered.
  2. Interested parties evaluate the situation.
  3. And vote.
  4. If one suggestion has more votes: it wins. End of.
  5. If there’s a tie, there are a couple of approaches that could be taken:

* someone with an overriding vote exercises it. The End.
* any options that we’re tied winners are dropped, and everyone revotes on just the remaining tied option (which won’t always be the case)
* if no clear vote result is made at this point, the proposal is not ready, so bench it for the time being, reverting to step 1 above.

There doesn’t need to be a consensus with these things. There just needs to be a decision.

–
Adam

1 Like
15

I think this is the cause of much of the unrest; the perception and expectation that ‘you lot’ (LAS) should be making these decisions, doing so on demand and in a timely manner.

Process clearly needs to be put in place, there is a discussion and movement towards that. Once we have that process, then this discussion can take place and in the context of “we” instead of “you lot”. In terms of LAS, the priority is “You lot need to get this process in place”. This is happening.

For now, the input on what people would prefer has to be welcomed. My own preference, “.lucee” and to not have optional alternatives.

2 Likes
16

I might have missed this, but would .lucee be both for templates and for classes?

As a suggestion I would say:
.lct → template
.lc → class

Couldn’t we use user voice or something similar (like trello) to vote on these?

17

Adam

I just asked Sean what his preference was? That was more for my interest im not sure what I prefer

The final decision was that we would support both the .lc and .lucee extensions.

A developer may choose to use the convention of .lc for their class/components and .lucee for their view files but this will not be enforced by the engine.

A

1 Like
18

In this case, lcm = equivalent of cfm and lcc = equivalent of cfc would make more sense.

Just keep only .lucee and everyone is happy. Why whould you need .lc too?

19

I like that notion. When working with PHP, I hated projects where I couldn’t tell if a particular file was a class or template. I had to take up the practice of naming things along the lines of Person.class.php (I don’t think such naming would work for .lucee?). That’s one thing that really struck me as nice about ColdFusion is that I didn’t have to open the file to know what was in it, because content was based on extension.

You could argue that you could gather that sort of information from the file’s surroundings, but really, you cannot guarantee what is in a .lucee file until you open it. I will probably stick to .lc for classes, and .lucee for templates.

20

Thank you! I’ll update the FW/1 issue. LuceeLang controllers and views will be supported in 3.5, alongside CFML. The other main thrust of 3.5 is to support Clojure controllers. DI/1 in 3.5 will also support all three languages, so you can write your model in a mixture of CFML, LuceeLang, and Clojure!