An object created dynamically could be created non-reflective. However, we do not think this is a good policy because, in some languages, it would be impossible to intercept operations performed during object construction. Moreover, it would probably lead to inter-level interactions, since the obvious place in which to specify a meta-object for the new object would be just after creating it.
Leaving an object non-reflective after its creation may also have security consequences, because a base-level object might use the knowledge that just-created objects are non-reflective in order to configure them with arbitrary meta-objects, unless prevented by class meta-objects.
However, leaving it up only to class meta-objects to decide when to disallow certain reconfigurations may be insufficient, or just too cumbersome. We advocate that the context in which an object is created, i.e., the meta-object of the creator, should be requested to provide a meta-object for the new object, so as to propagate reflective and security properties.
There are three reasons for the meta-object to return the meta-object it proposes for the new object, instead of requesting a reconfiguration: (i) returning is simpler; (ii) a reconfiguration request would allow the meta-object of the class of the object to overrule the proposal of the execution context; and (iii) allowing reconfigurations, or any other operations, before the new object is configured, could allow other meta-objects to take over the new object.
In order to prevent access to a new object before it is configured, a meta-object that rejects all requests controls the new object until the meta-object of the creator returns another meta-object.
At last, the messaging mechanism is implicitly used to notify the meta-object of a class about the creation of a new instance. This meta-object can keep track of the instances of the class, as well as affect their meta-configurations, by issuing reconfiguration requests.