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 > >