On Sun, Jan 22, 2017 at 1:14 PM, Denis Kudriashov <dionisi...@gmail.com>
wrote:
>
> 2017-01-22 11:54 GMT+01:00 Guillermo Polito <guillermopol...@gmail.com>:
>
>> Stef, we need to think about it carefullly. Streams are used in the
>> kernel for many tasks. Replacing them by a big framework will be a huge
>> drawback for bootstrapping purposes.
>>
>
> I would not say that Xtreams is bigger library then current streams in
> system. I measure it a bit:
>
> "5 packages: core parts + file streams + socket streams"
> ps := RPackageOrganizer default packages select: [ :each | each name
> beginsWith: 'Xtreams-' ].
> ps sum: [ :each | each definedClasses size ] "45".
> ps sum: [ :each | (each definedClasses sum: [ :c | c methods size ])
> + each extensionMethods size] "585".
>
>
Just curious, how about extension methods also?
>
> And current streams:
>
> Stream package definedClasses size "13".
> (Stream package definedClasses sum: [ :c | c methods size ])
> + Stream package extensionMethods size "304".
>
>
these are the kernel ones
> ({AbstractBinaryFileStream. FileStream} flatCollect: #withAllSubclasses)
> size."6"
> ({AbstractBinaryFileStream. FileStream} flatCollect: #withAllSubclasses)
> sum: [ :c | c methods size ]."226"
>
>
>
These are file streams, I'm not counting them in as kernel streams. And
maybe I'm wrong but Xtreams requires them, doesn't it?
> SocketStream methods size "81"
>
>
> Sockets are not in the kernel, they are loaded afterwards
> So in summary current streams are ~600 methods which is similar to xtreams.
>
So this is not quite true. In any case, I'm not simply against, I'd like
that we make a serious analysis of the impact before we integrate something
like this. How many things do change? Is it modular? Can we maintain it?
> But maybe current streams is much bigger code base. I not take into
> account compression part, encodings and others.
>
Again, not everything is in the kernel.
>
> Anyway idea to replace current streams completely is huge task. I doubt
> that we can move such way.
>
>
