On Jan 13, 2005, at 20:03, Clark C. Evans wrote: > Ok. I think we have identified two sorts of restrictions on the > sorts of adaptations one may want to have: > > `stateless' the adaptation may only provide a result which > does not maintain its own state > > `lossless' the adaptation preserves all information available > in the original object, it may not discard state > > If we determined that these were the 'big-ones', we could possibly > allow for the signature of the adapt request to be parameterized with > these two designations, with the default to accept any sort of adapter: > > adapt(object, protocol, alternative = None, > stateless = False, lossless = False) > > __conform__(self, protocol, stateless, lossless) > > __adapt__(self, object, stateless, lossless) > > Then, Guido's 'Optional Static Typing', > > def f(X: Y): > pass > > would be equivalent to > > def f(X): > X = adapt(Y, True, True) > > In other words, while calling adapt directly would allow for any > adapter; > using the 'Static Typing' short-cut one would be asking for adapters > which are both stateless and lossless. Since __conform__ and __adapt__ > would sprout two new arguments, it would make those writing adapters > think a bit more about the kind of adapter that they are providing. > > Furthermore, perhaps composite adapters can be automatically generated > from 'transitive' adapters (that is, those which are both stateless > and lossless). But adaptations which were not stateless and lossless > would not be used (by default) in an automatic adapter construction. > > Your thoughts? In some cases, such as when you plan to consume the whole thing in one function call, you wouldn't care so much if it's stateless. -bob
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4