Evaluate function references automatically instead of throwing error

I frequently get an error similar to this:

Can't cast Object type [user defined function (myMethod)] to a value of type [whatever]

Now, I know what this happens, I made a call like: rc.someObject.myMethod with forgotten parens instead of rc.someObject.myMethod(). Makes sense - its not a bad error message (it might be nice to say “You probably left off your parens” but I digress).

What if instead though, lucee notices that it is a function and evaluates it instead, then sees what happens? I would venture to say that 9 times out of 10, this error occurs when people are trying to use getters (and 8 our 10 statistics are made up on the spot). Something like rc.user.getUsername. Would it be possible for lucee to just automatically notice that its a function call and so evaluate it? Then everything just magically works… hopefully even if things are chained: rc.user.getCompany.getName would work just like: rc.user.getCompany().getName()

Now, this of course only works if the function call does not have any required parameters - and if it does then lucee would have to be smart enough to give a proper error message, something similar to to the above - not mask the error message because we were trying to be smart and guess at what the user wanted. If it made things easier I would say it would still be worthwhile if it only worked for methods with no arguments.

Now, all of this said, I would expect there to be some performance penalty - hopefully just at the compile stage but even if it was at runtime I would be willing to accept some slowdowns (to a point) for this.

There might be a case to be made that the syntax might be confusing to someone later on and that the error message is forcing you to write proper code, but im not convinced of that. I don’t expect it would take too much to decipher what is going on.


Those’re my thoughts.


Guessing the indentation of code is very dangerous, that is like autocomplete when writing text. Half of the time (or more) the guess is wrong.
I completely agree that a exception should be as precise as possible, but you should never guess the intentstion of code executed.

Oh: my other thought is that the error message is completely clear as-is too.

I don’t think it’s a language’s job to second guess or specifically cater for bad code (intentional or otherwise).

Garbage-in, garbage out.


Think of it as me proposing a new syntax.

I generally agree, but this code is not ambiguous is it? Can you think of another interpretation? We are talking about throwing a run time error, or attempting to do what I believe is unambiguously what the author intended. I am suggesting that this only happen when otherwise this specific error would be thrown.

My first reaction to this is to reply with snark, but I honestly don’t see the point you’re trying to make. We wouldn’t want to help newcomers to a language (or programming in general) understand where they went wrong?

Again, don’t think of this as me asking for the language to cater to my bad code - think of it as me asking for syntactic sugar to reduce noise and do what I obviously intended.

Well I think that would not help your cause. And I do like the way you took the meta approach of saying “here’s some snark” without actually having the bottle to actually provide some. That’s a wee bit of a disingenuous attitude, innit? Still: no harm done.

And we do. By providing a reasonably clear error message when they do something wrong.

Yes I know, Ryan. However we are entitled to not agree with you, which is an entitlement I’m exercising here.

Had you made the suggestion “make function-call parentheses optional where there can be no ambiguity” (like, say, they are in Ruby), then I’d probably have gone yeah, that’s a) a reasonable idea; b) a good example of syntactic sugar.

However your suggestion isn’t as fully realised as that, and - from your own description - really just catering to the fact you have a habit of forgetting your parentheses when doing method chaining.

One suggestion has a basis in enhancing the language, the other is just covering your coding mishaps. Perhaps you don’t see a difference there (willfully or otherwise), but I do. That’s also not to say I’m automatically right [grin]

For this particular suggestion, my chief reason to be wary of it is that in my experience, code interpreters that are left to second guess the coder’s intent seldom get it right, and are generally more trouble than they’re worth. I’d much rather there be a slight burden on the dev to get the code right, and not have the interpreter have to guess what they meant.


That wasn’t snark. Thinking of transitioning to name calling though.

I said the error message was pretty good. Just that it could be better. I want to make sure I understand, you disagree that adding a “You probably are missing parenthesis on your function call” would improve that error message? I’m not saying instead of the current error message, but in addition to it.

So you are saying my idea has no merit because I didn’t frame it the right way for you? Because I shared the muse for the request and you think im just being lazy? You don’t want to talk about the idea itself, just that you don’t like my motivations.

Take a step back and pretend like I came in and said

and then go from there instead of scolding me. This is exactly what I’m suggesting.

Again, I agree with this sentiment - it’s a good default position to take. I acknowledged as much in my original post. I am trying to see if it actually applies in this situation - my argument at the moment is that it is not ambiguous - it is not a second guess. I am asking if you can come up with any reason why that is incorrect. Can you think of a situation where this code might try and evaluate the function where you would actually expect and want it to throw an error?

My thought is it is completely unnecessary and convoluted. Functions are functions, and you indicate that you intend to call a function using parens. Omitting the parens indicates you are working with the function reference.

I’m assuming you want something like this?

// returns the user's name
function getUserName() {
    return rc.user.getName;

That would make sense, if you intend to actually return the user’s name. However, there are edge cases where one may actually want to return a reference to the actual getter function. I suppose one could do some introspection on the functions’ return types to see if maybe the getter should be called in that instance, or if the getter’s reference should be returned. All I see in that case is a non-performant syntax juggling act.

In any case, this is entirely unnecessary, as (I’m 90% sure that) Lucee already provides the option to automatically call setters/getters in this manner, at least for defined properties:

function getUserName() {
    return rc.user.name; // name doesnt exist, but getName does, so call getName 
                         // automatically

function setUserName(string name) {
    rc.user.name = arguments.name; // there is a setName function, call that instead 
                                   // of setting the "name" key into the user 
                                   // object.

Problem solved.

right - what im suggesting is that this would only kick in where it currently would throw an type conversion error. So

x = myObject.myFunction work work fine, it would have the object reference. #myObject.myFunction# would currently throw an error that myFunction cant be converted to a string, and so would attempt to be invoked instead.

fair enough - I have no idea of the performance of course, im not even sure its possible! but im only suggesting this happen in cases where today a specific error would be thrown.

There are many problems with the current implicit accessors settings, but the biggest one is that it only works for properties, not for methods you define on an object - so doesnt solve this particular use case.