I would address the problem with a compatibility layer like 'foo' reading withLegacyProtocol You have many options to add a protocol - simply add the protocol at XTReadStream/XTWriteSTream roots - just create another Xtreams wrapper, - use a Trait I wish I had lightweight traits, I mean with traitified classes created on the fly, with a simple naming like XTCollectionReadStream + TLegacyStreamProtocol in case we have to debug it, because this way I could also keep a clean Xtreams hierarchy in parallel with legacy at very low maintenance costs. However, this is going to be some work for sure, here is a rough measurement: (Stream withAllSubclasses inject: Set new into: [:allSelectors :aClass | allSelectors addAll: aClass selectors; yourself]) sorted size -> 594 (XTReadStream withAllSubclasses , XTWriteStream withAllSubclasses inject: Set new into: [:allSelectors :aClass | allSelectors addAll: aClass selectors; yourself]) sorted size -> 119 You certainly don't want to support 594 compatibility messages... Nicolas 2012/6/14 Igor Stasenko <siguctua@gmail.com>:
On 14 June 2012 08:33, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Tx
now there is a difference between adjustments and fully new API and I would have preferred adjustments.
Stef
IMO, Xtreams design is simply superior. But i agree, we cannot throw existing streams out.. too much things tied to them, and rely on using stream protocols. :(
-- Best regards, Igor Stasenko.