Add/Remove Attributes: All instance variables of NX objects are kept in the objects. The existing instance variables of an object can be queried, new instance variables can be added independently from classes, instance variable can be unset (removed) at runtime.

Dynamic Value Types: Tcl support already dynamic data types. Per default, all variables are strings. By performing operations on the values, the values are converted into more efficient internal datatypes (such as e.g. integers). On demand, the string representations of the values are updated. The change between different datatypes is performed dynamically.

Dynamic Binding: All method lookups in NX happen at invocation time. Other options would have been at compile-type (static binding) or at class/method definition time or object creation time. This strong form of dynamic binding is necessary for supporting dynamic behavior changes.

Dynamic Method Definitions: All methods of NX can ne created/modified/deleted at any time. This follows the idea of open object/class definitions. Some languages support closed class definitions, where all methods defined by a class have to be defined at class definition time and can’t be deleted later.

Dynamic method definitions are possible, since NX classes are runtime entities, i.e. they are special kinds of NX objects, which are able to manage the object life-cycles, and which provide instance methods for their instances.

Dynamic per-object Behavior: NX objects can have per-object methods. Per-object methods can be added/modified/deleted at runtime, independent from the class structure. Per-object methods are used e.g. for the definition of "class methods", which are methods applicable to the class object. On the contrary, instance methods are methods applicable to the instances of an class.

Altering Properties of Methods: Methods of NX have properties like e.g. call-protection (public, protected, private) or overwrite protection. These properties can be changed for every method at any time.

Re-Classing: The relationship between an NX object and its class can be changed at arbitrary times (i.e. as well after the object was created). Therefore, NX objects may change their class at any time. When the class of an object changes, the instance variables and the per-object methods are not modified.

Dynamic Class Deletion: Since NX Classes are special kinds of NX objects, it is possible to delete classes at runtime. When a class is deleted at runtime, it current instances are changed into instances of the next higher class in the class hierarchy (maybe the most general superclass nx::Object). At the same time, the class is removed from any sub-/superclass and mixin relationship.

Object/Class Redefinition: NX distinguishes between a new definition and a redefinition of an object/class. Per-default NX performs a full cleanup on a redefinition of a class. In an environment with dynamic code evolution, the behavior as stated above might not be desirable, since it might be complex to restore e.g. the class relationships when in an long-running server some classes are reloaded. The behavior of recreate operations can be defined from the script level.

The next scripting framework can be configured to perform keep the relationships upon recreates (convenience configure flag softrecreate). This option is e.g. used intensively in the OpenACS framework where e.g. packages can be reloaded for code evolution at runtime.

Dynamic Changes in the Class Hierarchy: All relationships between objects and classes are relationships that can be dynamically altered. Therefore, a class can e.g. change at any time its superclasses, or e.g. mixin classes (see below).

Ruby/Scala style mixins: Several Scripting Langauges support mixin classes. However, the semantics and therefore the applicability of this idiom for development tasks differs. For example the scripting language Ruby defines a concept named a "module", which can be used to mix-in a predefined behavior into multiple classes. When e.g. a module M is used in a class C, the methods of M are added to C with a lower precedence than methods of C. Therefore, C can refine the behavior of M. Similarly, mixin classes behave in Scala.

In NX this style of mixins can be realized via multiple inheritance, by simply adding M to the front of the list of superclasses of C. NX needs no special language construct. All changes to M (adding methods, altering the class hierarchy of M, …) are fully dynamic in respect to C and its instances.

Mixins as Decorators: The term "mixin class" in NX is used like specified in the decorator design pattern. The difference is that when e.g. a mixin class M is mixed into a class C, the methods of M are added to C with a higher precedence than the methods of C. Therefore, M can refine the behavior of C.

NX supports

Transitive Mixins: The per-class mixins are transitive, this means it is possible to extend also the behavior of a mixin class using per-class mixins.

Traits: In addition to mixins, NX supports a variant of traits [5]. Traits realize a composition mechanism for the reuse of methods. Contrary to e.g. mixin classes, the methods defined in traits are materialized in the target objects and classes. For every method inherited from a trait the composition behavior can be specified. This gives more fine-grained control over the reuse of methods and overcomes the "total composition ordering" limitation of mixins.

Filters and Mixins: XOTcl was the first language supporting language constructs for dynamically adding and removing design patterns to existing systems. The primary instruments for this are the so-called filter methods and mixin classes (see above).

NX has the exactly same functionality as XOTcl. These mechanisms can be used conveniently for debugging, tracing, and adapting a running system.

Guarded Code Injections: The code injection facilities are not only dynamic, but these can be made as well context dependent (a mixed-in method or a filter method is only applied when e.g. certain instance variables have certain values). This idea is similar to the notion of subject-oriented programming [6].