Add a way of creating specialised methods/ attributes per Tier

[0Hughman0]

Because the hierarchy cannot be nested all objects at each level need to have the same implementation.

This is fine, except sometimes a Sample in one Experiment may require some very different functionality in another.

One could add additional methods in their project.py, but this leaves the class definition a bit cluttered and unsafe.

One solution would be to add an attribute like spec short for specialist.

We then add a spec decorator that looks something like:

class MySample(Sample):
    ...
    @spec(['2', '1'])
    def specialised_method(self, *args, **kwargs):
        ...

The arguments to spec would specify which ids are allowed access to this method. This could even do fancy Regex things.

Then through some internal magic:

>>> smpl = project['WP2.1c']
>>> help(smpl.spec)
...
Docs for some specialised class with specialised method.
...

Something along these lines.

Alternitve implementations I'm sure would be possible.

[0Hughman0]

The alternative, which would be a big re-write would be to somehow make hierarchy not just a list, but something more complex e.g.

hierarchy = [
    Home, 
    (DefaultWP, {('1',): WP1, ('2',): WP2}),
    (DefaultSample, {('1', '1'): WP1_1, ('2', '7'): WP1_7}),
    (DefaultDataSet, {('5', '3', '1'): DSet5_3_1})
]

[0Hughman0]

I think to do so, we would need some sort of resolver class for resolving ids to tier types and then maybe each type has a factory registered or something.

[0Hughman0]

So

class RankResolver:

    def __call__(self, ids):
        return self.project.TIER_HEIRARCHY[len(ids)]

class TreeResolver:

    def __call__(self, ids):
        tier_cls = self.project.TIER_HEIRARCHY
        for id in ids:
            tier_cls = tier_cls.get(id)
        return tier_cls


class Project:

    def env(self, name):
        ids = self.parse_name(name)
        cls = self.resolver(ids)
        return cls(*ids)

[0Hughman0]

#130 helps to make this more possible down the line.

[0Hughman0]

I like this idea more and more, especially with the ideas around checking meta attributes in #119.

[0Hughman0]

I think a restriction will be that specialised classes will have to be subclasses of the default.