Warning: no files are visible, they have all been filtered.
#permalink
Details
| Participant | Role | Time Spent | Comments | Latest Comment |
|---|---|---|---|---|
| Moderator | 8 mins | |||
| Author | 3 mins | 2 | Worth a docstring to note that this is the base class for th... | |
| Reviewer - 100% complete | 61 mins | 11 | Although the following tests do test the implementation of I... | |
| Reviewer - 0% complete | ||||
| Reviewer - 0% complete | ||||
| Reviewer - 100% complete | 5 mins | 1 | The IStore interface is reasonable. I think it is the right ... | |
| Total | 78 mins | 14 |
#permalink
Objectives
Review the definition of the IStore interface - put, get, delete, query and the associated testing scheme. How can we make using interfaces easier? For instance how do we specify the return value behavior? how do we specify that it is a defered? Testing all implementations with an common test class using inheritance is a powerful first step to ensure that the behavior is the same.
|
|
|---|
|
Loading diff...
|
|
|
|---|
|
Loading diff...
|
In reply to the objective:
The return value of a function can be specified in the doc-string of the functions definition in the interface (the Python language does not support declaring return type).
The Twisted developers rely heavily on interface & implementation doc-strings (documentation string of a function) to specify return value types; they make it very clear (via the doc-string) when a function returns a Deferred.
When the return type is not a Deferred or a built-in Python type/structure, then it is good to be able to specify the qualified object class (i.e. module.Class) or, if provided, the interface of the return object (e.g ion.data.datastore.cas.ICAStoreObject).