On Sun, Jan 22, 2017 at 1:14 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:

2017-01-22 11:54 GMT+01:00 Guillermo Polito <guillermopolito@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.