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.
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.
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.
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.
Like most here I prefer .lucee but I don’t have a strong opinion about it.
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
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
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:
* 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
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.
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?
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
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?
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.
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!
Is this not an artefact of poorly organised applications, where classes aren’t in clear packages, and browseable files aren’t in the www or public dir, and general non-browseable script files in… erm… well we put them in /bin but that’s not right IMO. But you get my drift.
This is a real concern for legacy PHP applications, but would it be for .lucee applications, all of which will intrinsically be new?
FWIW, I rather like MyThing.class.php and someView.html.twig and that sort of thing. I’m pretty sure PSR-4 autoloading doesn’t like the .class.php extension though.
This schema wouldn’t work with .lucee as it stands, no: because classes don’t have names discrete from the file name. Perhaps that is something that needs addressing though? I’ve never liked that level of coupling.
If (and I very much mean “if” here) we were to make a distinsguishment (is that a word?) between classes and general scripts, does .lc and .lucee achieve this? I am not sure it does. Perhaps .lc and .ls would though? I say this because “Lucee” is the name of the whole project (and at the very least the whole language if we forget about the CFML side of things for the purposes of this discussion), so “.lucee” is a bit too all-encompassing to be used for differentiation, maybe?
And could it be said that there are three types of files, at least notionally? Classes, scripts and views? I suppose there are only two syntactical differences though: classes and… free-for-all-code. So I might be over-organising things in my head [grin]
–
Adam
That’s my sense too. For all my code, files in the controllers or model trees are all classes, and files in the views, layouts, or includes trees are all templates.
I think the CFML approach – of separate extensions for components and templates – is just a poor workaround for lack of organization by programmers.
Given the discussions around being able to declare classes inline – thus opening up the possibility of multiple classes in a file, as well as declaring classes locally in templates – I think that whole separation based on file extension just makes no sense at all. [I’m not much in favor of multiple classes per file but I’m seeing that creep into other modern programming languages and the sky hasn’t fallen yet so…]
That’s my point - you should be able to determine what it is based on surroundings, or even naming conventions, but you cannot absolutely guarantee what is in a file, if the extensions are the same.
That discussion indicates that inline class definitions are not available outside the template.
Lots of other languages seem to manage just fine with a single extension, despite some files containing classes and some containing “just code” (and some containing a mix of both).
Indeed, but that’s not relevant to my point: the ability to have inline classes means that any file could contain both classes and “just code”, so a separate extension for code that contains classes doesn’t really make sense in that context.