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 <siguc...@gmail.com>:
> On 14 June 2012 08:33, Stéphane Ducasse <stephane.duca...@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.
>
