Redux: Rename “component” to “class” in the Lucee dialect


Wow, that thread got derailed very quickly. Shall we try again, and stay on topic this time?

For me: yes. As has been discussed elsewhere, “component” always sounded weird to me. Why not stick with industry-standard terminology in .lucee?


Yes, sounds like the right thing to do in the Lucee dialect. Use class instead of component in a class definition, add class.lucee alongside CFML’s Component.cfc, rename getComponentMetadata() to getClassMetadata().

(and just to be clear: the CFML dialect would not change!)


I think the previous thread broke down when the bombshell of, “you can’t just rename component to class without renaming all the other references to component throughout the code” landed. Of course, you could, but its clearly not enough.

Support for using ‘class’ rather than ‘component’ seems to be pretty strong, the hiccup here is drawing a more far reaching proposal. Anyone, cough @adam_cameron cough, tenacious enough to flesh out the breadth of what should be changed and wrap it up in a proposal that we could move forward with?

The approach to implementing/designing .lucee

What if “class” was introduced more as an alias to “component” so both still worked and the internal gears would still be ok to use the term, but from a syntax perspective, the following would now also work:



class {}

And then functions such as getComponentMetadata() could be aliased as getClassMetadata(). I’m not sure if I like the idea of allowing for both since it might just dilute things a bit, but I thought I’d throw it out as a middle ground to allow for both without a full refactor needed.


If we’re talking about LuceeLang – i.e., files ending in .lucee – then there’s really no reason to keep <:component> alongside <:class> (assuming we even want to allow class files to be written in tags – again, an open issue) since you have to edit the code anyway and if you’re writing a conversion script, you’d just change cfcomponent to :class first and then go on to change <cf to <: and </cf to </:.

I’ll have more to say about this in one of my (probably long) posts later this weekend.


I don’t want to tread too much into the “negative encouragement” territory that we’re wary about here, but my position is sufficiently strong as to iterate it:


No “both”.

Make up your mind as to which one it is, and do that one. All instances wherein Railo did not do this was to the detriment of Railo/Lucee.

I make a point of over-emphasising this as there’s been a lot of fence-sittery in Railo which has bled into Lucee, and it helps no-one. My recommendation - for .lucee - is to take a position and stick with it. There is no requirement to cater to variations of the opinion or language.

No admin settings. No Application.lucee settings. Just implement it the way you mean it to be.


I tend to agree with @adam_cameron here. This is for LuceeLang and there shouldn’t be a mess and mix of aliases and switches if it can be avoided.

In this case it clearly can be avoided having both components and classes around - unless someone presents a very good case for leaving component in as an alias, I can’t see any reason why it should be.


Yes, to be clear, my ideal scenario is that we pick one and stick with it too. The only reason I suggested both was in response to Dom’s post which seemed to indicate that a complete switch to “class” was more work that it was worth based on some previous discussions. Since this topic seemed to imply a continued interest in having a “class” it seemed like perhaps the only way it would happen right now was too add it as additional syntax.

Another thing that I think ties into this that I’d need @micstriit to weigh in on is just how much of the back end code is shared between LuceeLang and CFML internally right now. (Cue Venn diagram) Obviously we want them to be able to be free to move apart wherever necessary without any ill affect on the other dialect. What I fear the reality right now may be, is that very large percentages of the two dialects share code a behaviors inside Lucee Server in a way that might not easily allow for major refactoring of one dialect without a fair amount of work to ween the two apart. Therefore if, for example, we decided to start passing arrays by value in LuceeLang that might take quite a bit more rearranging of the actual Java bits than you’d think by just saying “Let’s make LuceeLang do this”.

This isn’t ideal, it shouldn’t be a logical constraint, and perhaps it’s actually a non-issue and Micha already has a system in place to allow the two dialects to spring forth in completely different directions with very minor refactoring. Nonetheless, I see this as a potential growing pain once we start making sweeping changes to LuceeLang that really start to separate it (in good way, of course) from CFML. Perhaps it’s a concern for the Core Dev Team only and shouldn’t even be taken into account by us, but I’ve a feeling it may affect the “what’s possible” or even “what’s easy” categories more than we care to admit until we get some more ducks in a row.

Right alongside this discussion is “Should Lucee’s CFML engine and LuceeLang engine be shippable in completely separate packages?”. Adam already has a ticket in for that notion and it’s firmly off topic here so I’ll just provide the link and say no more:


I agree, that might become an issue.

However, I suppose should this occur it comes down to a decision about how much people want a fresh/clean approach at the “price” of a larger investment/refactoring needed to ween things apart.

Personally, I’d say I struggle to see value in LuceeLang if it’s not done right. Sure, from a practicality point of view one can always argue that the money to do “x” would better be invested in a new feature in the CFML layer, but that’s a decision that eventually LAS can (and will have to) make.



“component” is still supported as alias (hidden feature), what could be disabled at any time.