Rename "component" to "class" in the Lucee dialect

Should we rename “component” to “class” in the Lucee dialect?

We already had this discussion in the google group:
https://groups.google.com/d/topic/lucee/MzOw82hnzEg/discussion

ATM we still use the word “component” for components in the Lucee dialect, should we consider to use the term “class” instead in the Lucee dialect?

so instead of

component {
}

we do

class {
}

in our code. we could still support “component” as alias to make the conversion of an existing application easier.

What do you think?

4 Likes

I think from a conceptual point of view that’d be the right thing to do.

My only worry would be the potential chain of other things in the language terminology that needs to change then, too:

  • function vs method (so if a .lucee class still a function or a method now or do we need that keyword at all?)
  • documentation changes
  • general potential of terminology confusion between the CFML and the Lucee dialect.

i would prefer to stick with function, then we still support functions outside components and i think you should use the same keyword inside and outside a function, specially because you can inject them to components. php for example also has “class” and “function”.

Have in mind that lucee dialect components are working different than the cfml ones, they have a different runtime behaviour:

  • no separate variables scope
  • local scope comes first
  • maybe we get rid of the body constructor (see other topic)

So maybe it is a good thing to name them differently.

Just one observation there: my interpretation of the OO lingo is that “method” is a figurative term, and not referring to syntax / language specifics. An object or class’ methods are implemented via functions. A function is the syntactical implementation of same.

The notion of methods also only apply to objects or classes, whereas CFML has functions outside that context too (unlike Java, for example).

Whether or not .lucee decided to go with a syntax that did not require the “function” keyword when defining a function has no bearing on what the “thing” being defined is, and how it is described in its given context: a function, a method, a UDF etc.


Adam

I would prefer that the “function” keyword be optional - perhaps only when an access modifier is present. I’m not going to be dogmatic about it, but it just feels so much cleaner to just have:

class MyClass {
    public myFunction() {}
}

I’m less keen on the idea of including templates for the purpose of serving as mixins to classes. That has always felt wrong to me with components, and we have for the most part avoided that where I work - opting rather to have a base class with a method that copies methods from another component instance into the current instance. But even that is not ideal IMO. Honestly, I’m somewhat partial to, and would prefer something along the lines of PHP’s concept (not necessarily syntax) of Traits.

Well includes are as close as CFML gets to traits currently, albeit: not very close.

I’ve only really looked at formal implementations in Ruby and PHP. Ruby’s implementation is awful, and PHP’s traits are OK.

Interesting, btw, that you still position CFML source code files as “templates”! Sounds very 1996. And, yes, I know it’s a term still used in some quarters, but it really sounds very much like a pre-framework approach to CFML, and seems odd to me to be using it in the context of this sort of conversation. This is, btw, just a by-the-by observation :wink:

Yup, that’s a very good point. I agree with you and most likely the method vs. function terminology change won’t be much of a deal then.

I have to say, I’m not a fan of an optional “function” keyword. I think clarity is a benefit having in a language as opposed to multiple different yeah-nah-maybe-options.

I’m more than happy with having the “function” keyword required or not required at all.

In the latter case I suppose having the parameter list behind the identifier would make it known to the compiler that this is a function.

But whatever we do here, it should be a clear decision between either always requiring it or never required at all.

Making “function” optional can be confusing, then a script tag (acf syntax) can look the same way, avoiding this by making access modifier required (you need to have access modifier or “function”) seems not like a clear solution to me. +1 for function stil required.

1 Like

@adam_cameron
Interesting, btw, that you still position CFML source code files as “templates”! Sounds very 1996.

True 'nough, but I specifically meant templates as *.cfm files as opposed to components. Dunno what else to call them other than CFMs, I suppose :slight_smile:


@micstriit

I can see your point:

class Example {

    // define the savecontent method...
    savecontent (variable="something") {
        // which uses the savecontent script tag, ACF style
        savecontent(variable=variable) {
            echo("this is confusing");
        }
        // railo-style - doesn't seem to be as confusing to me personally... 
        // but i'm not everyone ;)
        savecontent variable=variable {

        }
    }

}

Even if the ACF-style script tag syntax were to dropped for the Lucee dialect, keeping the function keyword may still be necessary to prevent confusion. :confused:

Yes, that argument makes a lot of sense. +1 for function being required, too!

https://luceeserver.atlassian.net/browse/LDEV-83?jql=text%20~%20"Class%20syntax"

Which of the suggestions where actually implemented? Cause there were a lot of there.

From the commit log it appears it is just the rename of component to
class.

So, like, there’s still the expectation to call getCOMPONENTmetadata(), for example? Or do you mean that all the other things that were only tangentially related to component -> class, like mixins etc which were also rolled into LDEV-83 haven’t been done?

It’s not at all clear from the way the ticket has been maintained as to what “fixed” actually means, in this case :-/


Adam

These are the only commits (from a very cursory glance) that reference issue 83:
Test Cases:


“Fix”:

Looking at the “fix” commit, the only thing implemented in that commit was the name change for component->class for .lucee files. Now, some of the suggestions in the issue had already been implemented, or on their way to being implemented for CFCs. Namely: static, abstract, final, and most importantly the class keyword itself.

The suggestions remaining from the issue that to my knowledge have not been addressed yet are:

  1. drop the body constructor
  2. built-in mixin support
  3. non-comment annotations
  4. alternate property getter/setter syntax

I am OK with them not being implemented yet. However, I do think the issue workflow could be improved. Issue 83 should have been closed as duplicate, or wont fix, or something along those lines, and a new issue created to address the narrower scope of implementation. At the very least, there should have been a comment on the issue stating what exactly was going to be implemented.

But in fairness, the issue was specifically “implement a class syntax”, whatever that looks like. The examples listed were just suggestions, and not necessarily hard requirements. I do intend to open related feature requests (if they do not exist) for those missing pieces above.

Tickets should be atomar if possible and only address one issue. I will open a new ticket for this and change the status of the ticket 83. Yes we will also rename getComponentMetadata. Maybe simply merge with getMetadata.

1 Like

Continuing the discussion from Rename "component" to "class" in the Lucee dialect:

I wonder if there’s anything else “component”-ish we need to consider there? Giving it only a moment or so’s thought (and not very directed thought), nowt springs to mind.

Is there no useful distinction to maintain between getting a class’s metadata and an object’s metadata? I can’t say I’m that au fait with the result of either of them, that said. Something to consider, I think. If the two were combined, would it be a case of having this sort of thing:

Metadata getMetadata(String className)

and

Metadata getMetadata(Object object)

Where there are two implementations of Metadata: ClassMetadata and ObjectMetadata?

If so: good.


Adam

[lucee]\webapps\ROOT\WEB-INF\lucee\context\Component.lucee

And, no, I will not keep listing them individually [grin]


Adam

We will do a complete review to find out what else weneed to rename.
Component.lucee to Object.lucee,Adam.lucee,Eva.lucee,Base.lucee,…?