Message-ID: <495869965.28603.1394355043972.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_28602_753635653.1394355043972" ------=_Part_28602_753635653.1394355043972 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Since 1.5, Groovy supports the concept of "methodMissing". Thi= s differs from invokeMethod in that = it is only invoked in the case of failed method dispatch.
Typically when using methodMissing the code will react in some way that = makes it possible for the next time the same method is called, that it goes= through the regular Groovy method dispatch logic.
For example consider dynamic finders in GORM. These are = implemented in terms of methodMissing. How does it work? The code resembles= something like this:
Notice how, if we find a method to invoke then we dynamically register a= new method on the fly using E= xpandoMetaClass. This is so that the next time the same method is calle= d it is more efficient. This way methodMissing doesn't have the overhead of= invokeMethod AND is not expensive for the second call
Groovy also supports propertyMissing for dealing with property resolutio= n attempts. For a getter you use a propertyMissing definition that takes a = String argument:
For a setters you add a second propertyMissing definition that takes a v= alue argument:
As with methodMissing you will likely want to dynamically register new p= roperties at runtime to improve the performance of you code.
You can add methodMissing and propertyMissing that deals with static met= hods and properties via Expand= oMetaClass