This module exposes the composite design pattern in an easy to use way
which attempts to minimalise the repetitive overhead.
The composite design pattern is an alternative to top-down inheritance
when there is no clear hierarchical chain. Examples might include assigning
roles to entities - where an entity can have any variation of roles.
Methods between composite parts can return all manor of variable types,
therefore xcomposite gives you a library of decorators which you can utilise
to define how the collective set of results should be wrangled and returned.
__Note: This is currently pre-release__
## Installation
You can install this using pip:
```commandline
pip install xcomposite
```
Alternatively you can get the source from:
https://github.com/mikemalinowski/xcomposite
## Code Documentation:
https://mikemalinowski.github.io/xcomposite/
## Composition Inheritence
You can utilise this pattern like this:
```python
import xcomposite
# -- Inheriting off the composition class means that your class can
# -- immediately bind any other class of a Composition type.
# -- You should declare (through composite decorators) what the
# -- expactation is of any bound methods. This allows you to tailor
# -- exactly how the results should be combined/returned.
class A(xcomposite.Composition):
@xcomposite.Extend
def items(self):
return ['a', 'b']
class B(xcomposite.Composition):
@xcomposite.Extend
def items(self):
return ['x', 'y']
# -- Instance any one of the classes, and bind it to the instance
# -- of the other
a = A()
a.bind(B())
# -- Call the items method, noting that the result is the expected
# -- list of items from the 'items' call of both A and B
print(a.items()) # Prints ['a', 'b', 'x', 'y']
```
# Non-Intrusive Composition
The above example shows how this module can be used when you have the
ability to structure your classes with the composition module in mind. However
if you are using classes which you can only use passively you can take the
following approach:
```python
import xcomposite
# -- Define a class which we do not want to have inheriting
# -- with decorators. This examplifies a situation where the
# -- classes to be bound are third-party.
class A(object):
def items(self):
return ['a', 'b']
def count(self):
return 2
class B(object):
def items(self):
return ['x', 'y']
def count(self):
return 3
# -- Because we cannot bind directly within the A or B class
# -- we instead define a composition wrapper. This is much like
# -- an abstract - it has no functionality but declares which
# -- methods should be considered bound and how they should be
# -- handled.
class Wrapper(xcomposite.Composition):
@xcomposite.Extend
def items(self):
# -- Note that this wrapper forms part of the composite
# -- but we do not want its return values passed through
xcomposite
return xcomposite.Ignore
@xcomposite.Sum
def count(self):
return xcomposite.Ignore
# -- Instance our wrapper and bind an instance of A and B to it
inst = Wrapper()
inst.bind(A())
inst.bind(B())
# -- Call the items method, noting that the result is the expected
# -- list of items from the 'items' call of both A and B
print(inst.items()) # Prints ['a', 'b', 'x', 'y']
# -- Printing count gives us 5, because we decorate with a Sum
# -- decorator meaning all the values will be added together
print(inst.count()) # Prints 5
```
## Examples
There are two examples which come packaged with the module which attempt to
demonstrate simple use-cases which just print output for inspection. You can
run these demos with the following code:
```python
from xcomposite.examples import game
game.demo()
```
```python
from xcomposite.examples import personnel
personnel.demo()
```
## Testing and Stability
There are currently unittests which cover most of composite's core, but it is not yet exhaustive.
## Compatability
This has been tested under Python 2.7.13 and Python 3.6.6 on both Ubuntu and Windows.
## Contribute
If you would like to contribute thoughts, ideas, fixes or features please get in touch! mike@twisted.space
Metadata
Release files for xcomposite 1.0.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| xcomposite-1.0.1.zip | 23.9 kB | Without provenance | Details for xcomposite-1.0.1.zip |
Release files / xcomposite-1.0.1.zip
| Download URL | xcomposite-1.0.1.zip |
|---|---|
| Size | 23.9 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
8950765c4677a987d8d3d27b2523fc8bbd2406799d7fec52075511af65798ffc
|
|
BLAKE2b-256 checksum How to use checksums |
9ee19a9d3b6caf30a897ec50394078da3d65affb0cef870b6ed3f241bfd15f9e
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/1.12.1 pkginfo/1.4.2 requests/2.20.1 setuptools/5.7 requests-toolbelt/0.8.0 tqdm/4.28.1 CPython/2.7.7
|
Security for xcomposite 1.0.1
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.