anchor.diff:  p1.getBestFriend(); // returns p2
   gc1.getRefers(); // returns c2, a Customer proxy wrapping p2
   ----
  -====
   
   
   Notice that, by the time p1 becomes GoldenCustomer, p2 must have already become a Customer themselves, otherwise a runtime exception will be thrown since the very definition of GoldenCustomer would have been violated.
  
positive.code:     $sc.setDiscount( ... ); // soft setter
  end
  ----
  ====
  
  
  A core object also holds a reference to all its proxies, so that it is possible to track which type(s) have been added to an object, using a sort of dynamic "instanceof" operator, which we called isA.
  The operator can accept a String, a class literal or a list of class literals.
  In the latter case, the constraint is satisfied only if all the traits have been donned. 
  
  ====
  [source]
  ----
  $sc : GoldenCustomer( $maxExpense : maxExpense > 1000,
                        this isA "SeniorCustomer", this isA [ NationalCustomer.class, OnlineCustomer.class ]
  )
  ----
  ====
  
  
  Eventually, the business logic may require that a trait is removed from a wrapped object.
  To this end, we provide two options.
  The first is a "logical don", which will result in a logical insertion of the proxy resulting from the traiting operation.
  The TMS will ensure that the trait is removed when its logical support is removed in the first place.
  
  ====
  ++++
  <programlisting>then
      <emphasis role="bold">don</emphasis>( $x, // core object
           Customer.class, // trait class
           true // optional flag for logical insertion
      )</programlisting>
  ++++
  ====
  
  
  The second is the use of the "shed" keyword, which causes the removal of any type that is a subtype (or equivalent) of the one passed as an argument.
  Notice that, as of version 5.5, shed would only allow to remove a single specific trait.
  
  ====
  ++++
  <programlisting>then
      Thing t = <emphasis role="bold">shed</emphasis>( $x, GoldenCustomer.class ) // also removes any trait that</programlisting>
  ++++
  ====
  
  
  This operation returns another proxy implementing the org.drools.core.factmodel.traits.Thing interface, where the getFields() and getCore() methods are defined.
  
negative.code: If an @Alias is provided, its value string will be used to resolve mappings instead of the original field name.
  @Alias can be applied both to traits and core beans. 
  
  [source]
  ----
  import org.drools.core.factmodel.traits.*;
  declare trait GoldenCustomer
      balance : long @Alias( "org.acme.foo.accountBalance" )
  end
  
  declare Person
      @Traitable
      name : String
      savings : long @Alias( "org.acme.foo.accountBalance" )
  end
  
  when
      GoldenCustomer( balance &gt; 1000 ) // will react to new Person( 2000 )
  then
  end
  ----
  
  More work is being done on relaxing this constraint (see the experimental section on "logical" traits later). Now, one might wonder what happens when a core class does NOT provide the implementation for a field defined in an interface.
  We call hard fields those trait fields which are also core fields and thus readily available, while we define soft those fields which are NOT provided by the core class.
  