At 10:09 AM 1/14/05 +0100, Just van Rossum wrote: >Guido van Rossum wrote: > > > Are there real-life uses of stateful adapters that would be thrown out > > by this requirement? > >Here are two interfaces we're using in a project: > > http://just.letterror.com/ltrwiki/PenProtocol (aka "SegmentPen") > http://just.letterror.com/ltrwiki/PointPen > >They're both abstractions for drawing glyphs (characters from a font). >Sometimes the former is more practical and sometimes the latter. We >really need both interfaces. Yet they can't be adapted without keeping >some state in the adapter. Maybe I'm missing something, but for those interfaces, isn't it okay to keep the state in the *adapted* object here? In other words, if PointPen just added some private attributes to store the extra data? >Implicit adaptations may be dangerous here, but I'm not so sure I care. >In my particular use case, it will be very rare that people want to do > > funcTakingPointPen(segmentPen) > otherFuncTakingPointPen(segmentPen) But if the extra state were stored on the segmentPen rather than the adapter, this would work correctly, wouldn't it? Whereas with it stored in an adapter, it wouldn't.
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