-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathTODO
42 lines (29 loc) · 1.49 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
These are more like ideas than like unimplemented features. I.e. they
are not obviously good or have both benifits and drawbacks.
NAMED SIGNALS
It would look like this: there is a single object (maybe
`SignalFactory' or `SignalCollection', don't know yet.) Its
__getitem__() operator is overriden to get single string---name of
signal---and return `AbstractSignal' subclass instance, an internal
proxy consisting of reference to the factory and the name.
Factory would maintain a single list of handlers, indexed by signal
names somehow. This makes them useful: a single factory would take
less memory than several `Signal's.
Note that factory would _not_ implement `AbstractSignal' itself, only
returned proxies would.
It is unclear if a factory should impose any restrictions on signal
names. Probably yes, at least optionally.
Sample usage would look like this:
factory['create'].connect (...)
factory['create'] (some, list, of, arguments)
Optimized usage (that avoids creating proxies all the time):
signal = factory['create']
signal.connect (...)
signal (some, list, of, arguments)
In both cases, `create' is a name of the signal and has absolutely no
special meaning to `factory'.
As an alternative to __getitem__(), factories may provide a custom
__getattribute__() instead, with the same meaning. I.e. instead of
`factory['create']' you'd write `factory.create'. On the upside we
have a nicer syntax, on the downside we lose possibility to add any
methods.