Ok. So while the “decorator” approach looks fantastic it will obviously have 
its own drawbacks.

Discussing this on the mailing list is very tiering, so I suggest that this 
should be discussed during the next sprint or Pharo days. Since I will not be 
able to attend either one, can I ask one of you to take responsibility for 
this? Sven or Doru maybe?

Cheers,
Max

> On 11 Jan 2016, at 08:10, Sven Van Caekenberghe <s...@stfx.eu> wrote:
> 
> 
>> On 08 Jan 2016, at 21:15, stepharo <steph...@free.fr> wrote:
>> 
>> Sven
>> 
>> may be should do the following:
>>   - introduce the best solution (not using your and henrik decomposition)
>>   - continue to think about it.
> 
> There is no intermediary solution, we'll continue to think about it.
> 
>> I would like to see if Xtreams does not go in the same direction too. But I 
>> do not have the code at hand to think about it.
> 
> Xtreams does not solve the problem either, I think.
> 
> The key question is: can you write operations on objects, generic containers 
> of element objects, that depend on the fact that the element objects are of a 
> certain type (or protocol), but that might fail and make completely no sense 
> for others.
> 
> Consider the 'data get/put' category on PositionalStream with operations like 
> #int32 and #int32: - these assume that this are byte streams. But in my book, 
> streams can be anything, colors, records, points, fonts, ... 
> 
>> Stef
> 
> 


Reply via email to