From f3356252c18d2045759e6af5cb514b95d4b177c1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marco=20Aur=C3=A9lio?= Date: Tue, 4 Apr 2017 23:40:55 -0300 Subject: [PATCH] Filling missed specification points in the README. --- README.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index ac48d80..d47fca4 100644 --- a/README.md +++ b/README.md @@ -40,7 +40,7 @@ of all, to compose seamlessly on an unknown object, the library must yield a fre some assumptions over this unknown object (I mean, assumptions intended to _modify_ the passed object). So, to avoid inconsistent assumptions, fresh things are generated and they should replace explicitly their respective target objects (surely, where it is planned to do that). By second, these fresh objects must behave almost like their target -objects counterparts, with minor and needed variations, if possible. In this library, a fresh object have its own identity, +objects counterparts, with minor and needed variations, if possible. In this library, a fresh object has its own identity, and its own "state", but, for example, the target object's meta-table semantics are preserved in some way (with the exception of the `__newindex` meta-method, which is used to provide a "local state" for this fresh object). @@ -189,6 +189,16 @@ But a syntax sugar is provided as well: local talent3 = talent1 + talent2 ``` +During talent application and talent activation, detected conflicts are raised under the standard below: + +```lua +local reason = require ('talents.internals.reason').conflict (selector) + +error (reason) +``` + +Where `selector` is the field which the system have detected an arising conflict. + ### Contextual Activation