class A {}
println A.metaClass

this call DefaultGroovyMethods#getMetaClass(Class), which will set an ExpandoMetaClass for A, and this will eb the default fro A from here on. So, when you create a new instance and ask for the metaClass property of the instance, then it will return the current default, which is ExpandoMetaClass. Thus

def a = new A ()
println a.metaClass
println A.metaClass

will then print ExpandoMetaClass. Now in the code

class A {}

A will have the normal default MetaClass, which is MetaclassImpl. and since you didn't change the class yet, a

def a = new A ()
println a.metaClass

println A.metaClass

println a.metaClass
def b = new A ()
println b.metaClass

Basically, that means that if you want to do instance-level metaClass mangling based on the ExpandoMetaClass, you have to do: "A.metaClass" before "def a = new A()" or you have no guaranties as to the type of "a.metaClass". Which, I suppose, is a just fine work-around assuming you know what type your "A" is or can control where it's being instantiated.

Why is MetaClassImpl exposed at all? Why don't all classes have a single ExpandoMetaClass (which could be generated through a CacheMap[1]), which is cloned as part of the constructor call or on the first access to a.metaClass or whatever?

I encountered this bug, BTW, while working on a blog post [2].

[1] http://code.google.com/p/jconch/wiki/CacheMapExamples
[2] http://enfranchisedmind.com/blog/2008/06/24/functional-metaprogramming-ruby-groovy/ – see right above "Let The System Handle The Clean-Up"

Anyway, I forgot to mention, that there isa simple way of ensuring that all MetaClasses will be ExpandoMetaClass and that is by ExpandoMetaClass.enableGlobally()...see http://groovy.codehaus.org/ExpandoMetaClass With this method (if it is called before any MetaClass action is done) you can ensure that.

> "what do you say when you set a.metaClass to something custom and a later A.metaClass would change this to ExpandoMetaClass?"
I'd say that A.metaClass shouldn't be changing it to ExpandoMetaClass, it already should have been an ExpandoMetaClass. And I'd say property accessors shouldn't have side effects.

The issue of whether global changes to the static metaClass impact and instances is totally tangential to this conversation. Unsurprisingly, I've got opinions there, but we'll leave that to a more appropriate forum.

Sounds like I'm best off calling ExpandoMetaClass.enableGlobally() before trying to do any metaprogramming in Groovy. Either that, or just holding off until Groovy 2, particularly if things are going to change substantially at that point.

I want to write a method that attaches a new method to an object. Something like:
def tag(a) {
a.metaClass.tagged << { true }
}
(As a more realistic example, see my blog, where I try and add a property to an instance.)

The problem is that whether or not that code will explode depends entirely on whether or not the instance I passed in has had it's static metaClass property accessor called. And I won't know if it passes or fails until runtime. So it's very possible that a debug statement in some far away piece of code (which statically interrogates the metaClass) might make this code OK, and bypassing/removing said debug statement would make this code explode.

That kind of awkward code dependency is a major issue. Glad to hear the Groovy team is looking into it for the Groovy 2 release.

about your code example... I guess you got something wrong.. as soon as you do for example "println a.metaClass"the property will not be null. And this property is not a static one, it is a property of the object. So if you need to ensure that you can add the method/property, you have to check the MetaClass first:

def tag (a) {
  if (a.metaClass.getClass()==MetaClassImpl) {
    ExpandoMetaClass.enableGlobally()
    a.metaClass = null
  }

  if (a.metaClass instanceof ExpandoMetaclass) {
    a.metaClass.tagged << { true }
  } else{
    throw new RuntimeException("the tag object has an unexpected metaclass: $a.metaclass")
  }
}