Inheritance

It's also possible to extend existent talents and thus, reuse some definitions, requirements and even some unwanted conflicts (surely, nobody likes to inherit "errors"). The only important points are:

• If you are willing to define a requirement, but it is already provided on the parent talent, this requirement is discarded anyways by the child talent.
• It is possible to "solve" conflicts through "overriding". If you provide some definition, and in the parent talent it is actually a conflict, the conflict is ignored and the child talent takes that definition. Note that conflicts are unaccessible values (different of requirements), so they only arise on some certain specific conditions of symmetrical sums. If this conflict is due two different primitive values of the same type (e.g, numbers such 0 and 1), it's not quite bad to override such conflict, but if it is due two different and unrelated functions/methods accidentally sharing the same selector field, codes relying specifically on some of these parts might be broken with your own definition. This is the why of the advice for contextual activation on top of this documentation.

Despite such "issues" and "problems" of inheritance, to use inheritance between talents we just write:

-- assume that `parent` contains our parent talent --

local child = talents.extend (parent, definitions)

Talent inheritance also works internally in the same way of talent definition: the passed definitions are cloned through an iteration (using the passed configuration's iterator). Shallow cloning is used in the inheritance internals, but deep cloning can be provided (with a custom configuration) as well.