Lucee 5 beta: the PHPification of CFML

G'day:
I continue to raise my eyebrow at some of the decisions the Lucee Team have been making regarding work they've been doing in Lucee.

Here we have "Lucee_5_Functions_Tags", which lists three new, roughly similar functions (by their own admission):

createComponent()

I've discussed this already ("Lucee 5 beta: createComponent()"). For the purposes of this article, the chief problem is it's misnamed. It doesn't return components. it returns objects. Like its - correctly-named - precessor that it's supposedly replacing does.

javaProxy()

This is roughly analogous to the above, except it returns a Java proxy object (same as how createObject("java") does now. It's got some additional stuff added into it for OSGi support. But in most situations, it's analogous to createObject("java").

However this is named wrong too. Something called JavaProxy would most likely be a class (because its name is a noun). It would not be a function (which should impart the idea of doing some sort of action). Now I know "proxy" can be a verb, but the appropriateness (or intent) here is questionable, I think. On the other hand I could see how this might be valid:

myJavaProxy = new JavaProxy()

or this:

myJavaProxy = createJavaProxy()

or even this:

myJavaProxy = JavaProxy()::create()

The second one sticks closer to the rest of CFML's headless functions, but I dunno if that's something to be encouraged? CFML is moving into the territory of method-calling not function calling, so I'm actually fine with either of the latter two options.

But what they've implemented is wrong, IMO. It's at odds with the rest of the language, is semantically sub-par.

webserviceProxy()

I've got nothing to add about this, other than the fact it has the same problems as javaProxy() does.

Also all of this stems from Micha's desire to deprecate createObject() for some reason, which I've yet to see a good explanation for.

createObject()

And we'd still need createObject() for creating proxies for .Net objects or assemblies, I guess? Neat.

Summary

• createComponent() - creates an object, same as createObject(). Except named badly
• javaProxy() - analogous to createComponent(), created for the same reason, has completely different naming standard (and that standard is also not great in and of itself).
• webserviceProxy() - as above, and no real need to create it.
• creatObject() - lingers on, covering most but not all the ground covered by the above, does it slightly differently, and does some stuff these replacements do not.

If only webservice_proxy() had an underscore in there, I'd be able to declare Micha as a PHP spy.

Now whilst this is only a short article, it does - on the face of it - seem like fuss over not much. TBH, I don't care so much about these functions (however it ought to be sorted out, and I will be raising tickets accordingly: 282), but I am concerned about how I see CFML's design going off the rails a bit more than I feel comfortable with, with some of the stuff the Lucee Team is doing. I hasten to add that the work on the general engine seems fine, but I'm just talking about the CFML language. If I was to be uncharitable and unhelpful, I'd simply observe that perhaps they ought to stick to just mirroring what Adobe does. But - let's face - that'll not do us any favours either. What I do think needs to happen is the language design decisions need to be taken away from the Lucee dev team. It seems to me like it's basically Micha doing all the design, and I do think he's out of his depth. Furthermore, I've been looking more at how PHP does things recently, and when they decide to implement a feature, they put the concept out to the community first, and then let it be discussed, fine-tuned, thought about, torn-to-shreds, etc. Ultimately the design should not be done by committee, but the decision makers (and the pool of ppl who are the decision makers needs to be deepened, I think) should utilise the expertise, use cases and whim of the community to fine tune anything they're thinking of doing. Especially in an open source solution there's no corporate secretiveness to worry about (a la Adobe), it's supposed to be a collaboration. I know a bunch of people who might not have time or ability to write the actual implementation, but there's a great pool of talent about who can lend a hand. All Lucee needs to do is ask. And that sort of PHPification in CFML should be welcomed.

Righto.

--
Adam