Comments on: Groovy Objects in CFML (a la Ben)

By: Ben Nadel

Ben Nadel — Thu, 24 Sep 2009 12:57:46 +0000

I've been trying to play around with Groovy, but I feel so handicap because I am trying to, perhaps, get too dynamic without truly knowing much about the language. Everything in CF is so easy, it seems, but I guess it's just that I don't know the syntax in Groovy yet.

This morning, I tried to play around with two ideas that stopped me dead in my tracks:

1. Extending CF classes
2. Overwriting cast operators

1 – its seems that a lot of the CF classes are considered "final"?? and Groovy will not let me extend them. :(

2 – this might just be something that is not possible across the groovy / cf context. Plus, I probably don't have the correct syntax.

… sorry, I know this comment is a total non-sequitur.

By: Sean Corfield

Sean Corfield — Wed, 23 Sep 2009 19:35:43 +0000

Ah, I misread you, sorry. Again, I don't think Groovy's missingMethod() is slow per se but what you then do in order to process the 'missing' method call may well be slow. Of course, in Groovy it can optimize 'regular' method calls down to native Java calls so compared to that, both Groovy's missingMethod() and *any* of CFML's method calls are slow since they look a lookup and, potentially, reflection...

By: Ben Nadel

Ben Nadel — Tue, 22 Sep 2009 21:02:32 +0000

@Sean,

I was saying that onMissingMethod() was *not* slow. In fact, I think I was actually thinking of a conversation that you and I had (online) in regards to that. I was saying that I was surprised that Groovy's missingMethod() was considered slow, since CF's was considered fast.

By: Sean Corfield

Sean Corfield — Tue, 22 Sep 2009 20:48:02 +0000

Where did you read that onMissingMethod() was slow? The actual invocation is very fast because it's built right into the function lookup so it adds only a few ms to the call. Of course, performance depends on what you do *inside* onMissingMethod() …

I've used onMissingMethod() very successfully to provide automatic delegation across tiers in an application as well as generic CRUD methods which cuts out huge amounts of boilerplate code. Yes, there's an overhead in the logic *inside* oMM() that decodes what the method should do and how to process the 'real' call but in the grand scale of things the RAD benefits overwhelmed that completely for Phase I of a project…

By: barneyb

barneyb — Thu, 17 Sep 2009 22:53:45 +0000

I honestly don't know. I'd expect missingMethod to be significantly slower than a "real" method invocation, but with how much faster Groovy operations are than CFML ones, I really can't say if it's relevant. If a real method call takes 5 nanoseconds, and a missingMethod call takes 500 nanoseconds, that's 100 times slower. But if a normal CF method call also takes 500 nanoseconds, then Groovy's missingMethod is fast. Those numbers are completely baseless, they're merely for illustrative purposes. You'd have to do testing to see if the performance actually mattered.

By: Ben Nadel

Ben Nadel — Thu, 17 Sep 2009 22:45:38 +0000

I was looking up missingMethod and some articles said that it was very slow. Is this true? I only ask because in the CF world, it has been explained that since CF checks for the target method before sending the message to OnMissingMethod(), it actually has almost no overhead (and no exception handling). Does Groovy work differently? Or, is the "slow" that Groovy is talking about relative?

By: barneyb

barneyb — Thu, 17 Sep 2009 18:36:09 +0000

Yeah, you're right. It's actually a compiler hack that does it, not a runtime features, and CF doesn't have it. E.g. when you write myVarargsMethod(1, 2, 3, 4), it actually compiles down to the equivalent of myVarargsMethod([1, 2, 3, 4].toArray()), so at runtime it's actually a single Object[] that is passed to the method. CF can't do that because it's reflection support is apparently still in Java 1.4 land. You could use missingMethod to implement your init() method; then you'll get the arguments as a collection along with the method name.

By: Ben Nadel

Ben Nadel — Thu, 17 Sep 2009 18:20:28 +0000

Actually, I think I read that link this morning! I think there is a problem – the variable arguments seemed to work perfectly fine from within Groovy; but, I think when called from ColdFusion:

… I was method signature errors that CF was trying to find this:

method( Object[] )

It looks like within the Groovy context, N methods => Object[] args happens implicitly; but, when going from CF to Groovy, you need to explicitly define the collection.

Of course, again, I am new – I might very well be way off here. But, that's why I went with the 10 explicit args rather than (Object… args) notation.

By: Ben Nadel

Ben Nadel — Thu, 17 Sep 2009 18:16:32 +0000

Ah, ok, cool. I just figured CFInvoke / CFInvokeArgument was some sort of more elegant dynamic code execution. I'll be sure to check out that link.

And, again, thanks for the CFUNITED presentation – it was very inspiring.

By: barneyb

barneyb — Thu, 17 Sep 2009 17:46:01 +0000

CFINVOKE and createObject() are both backed by reflection, almost identical to the way you implemented it in your code. Obviously it supports variable numbers of arguments in a cleaner way (not a list of ten), but the gist of it is identical. Check out the first example at http://www.javalobby.org/articles/groovy-intro3/ for some goods about variable numbers of arguments. It's just as easy (perhaps easier) as with CFML. :)