If you do the “x.metaClass” without doing the “X.metaClass” beforehand, you get a metaClass — of type MetaClassImpl, which does not have the same functionality as an ExpandoMetaClass. But if you do X.metaClass first (before x is instantiated) then you’ll get an ExpandMetaClass when you do “x.metaClass”.

This is what I was asserting as a bug.

Which is what you are manually doing when calling X.metaClass, for the class X.

Really? By accessing the metaClass, I’m manually attaching an ExpandoMetaClass? I thought I was just checking the static metaClass field off of the X class.

This is bug #2 in this issue: accessors should not have side effects.

You can talk on the Jira bug, but you might have better luck hitting the Groovy dev mailing list and asking exactly what *is* the intended behavior for instance-level metaclasses.

“Odd that an error isn’t thrown in this case, then.”

Yes odd indeed, I was expecting that piece of code to fail.

I guess for performance reasons an object either has a metaclass or not attached to it. The default being not. the ExpandoMetaClass.enableGlobally() will probably just make sure that ExpandoMetaClass is enabled on all classes by default.

Which is what you are manually doing when calling X.metaClass, for the class X.

that being said, the code you posted is in contradiction with the API, so I might let myself be heard on that long JIRA ticket soon :P

something is not quite right, I might change my vote to bug soon

There seems to be two general minds on this conversation (hence the “Bug or Feature” question).

One stance is that the entire concept of an “isntance metaClass” is nonsensical — that behavior is defined at the class level, so mangling the behavior of an instance mandates mangling the behavior at the instance level.

This is not Groovy’s approach.

Groovy allows mangling of instance metaClasses — indeed, you can assign a whole new metaClass to a particular instance, which will completely rewrite its type. And it also allows mangling existing metaClasses at an instance-by-instance level (see my previous example, and the JIRA ticket I opened). To me, this is the way Groovy should work, since the type system is already de facto out the window. Duck typing and API mangling makes the class’s type a suggestion — at best — as to a type’s behavior. The pseudo-object functionality offered by hashes even further blurs the lines around types. So, given that types aren’t terribly relevant in Groovy, I’d say that we should go ahead and let mutability happen wherever: we’ve already got enough rope to hang ourselves, why not actually get enough to do something useful? And this behavior is inline with the cool kid on the block (Ruby).

Now, whether this is the best approach or not is a conversation for a different post.