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.