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.
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
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.
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.
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 :-/
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:
drop the body constructor
built-in mixin support
non-comment annotations
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.
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?
