zipped and unzipped methods for ByteArray
Can I add ByteArray>>#zipped and #unzipped methods the way it is for String? I want to compress bytes before sending through internet, for example. Do you agree? Thanks, Juraj
This seems related to adding 'easy of use' methods to String. There are many different compression schemes (zip, bzip, bzip2, gzip, ...), are we going to add them all ? How much do we want to couple different parts of the system ?
On 25 Feb 2015, at 16:23, Juraj Kubelka <juraj.kubelka@gmail.com> wrote:
Can I add ByteArray>>#zipped and #unzipped methods the way it is for String? I want to compress bytes before sending through internet, for example.
Do you agree? Thanks, Juraj
25. 2. 2015 v 12:28, Sven Van Caekenberghe <sven@stfx.eu>:
This seems related to adding 'easy of use' methods to String.
There are many different compression schemes (zip, bzip, bzip2, gzip, ...), are we going to add them all ?
How much do we want to couple different parts of the system ?
I prefer to couple the compression schemes with String and ByteArray. Methods like #zipped, #unzipped are not that simple and it is not well apparent how to use that compression scheme. Cheers, Juraj
On 25 Feb 2015, at 16:23, Juraj Kubelka <juraj.kubelka@gmail.com> wrote:
Can I add ByteArray>>#zipped and #unzipped methods the way it is for String? I want to compress bytes before sending through internet, for example.
Do you agree? Thanks, Juraj
I think I did something similar in Squeak, but can't remember exactly... http://source.squeak.org/trunk/Compression-nice.43.diff http://source.squeak.org/trunk/Compression-nice.44.diff ByteString zipped should better return a ByteArray because the zipped thing is all but a String (it is encoded...) But if we do this then what happens to WideString zipped ??? what should it be ??? Are we sure that we can unzip it back to a WideString ? My answer was that ByteString zipped -> ByteArray -> ByteString and WideString zipped -> ByteArray -> WideString, but it supposes that the zipped byte array has a length multiple of 4... Then I don't remember if it really works for WideString... But String is just a facade, all the effective job is performed in ByteArray. 2015-02-25 16:52 GMT+01:00 Juraj Kubelka <juraj.kubelka@gmail.com>:
25. 2. 2015 v 12:28, Sven Van Caekenberghe <sven@stfx.eu>:
This seems related to adding 'easy of use' methods to String.
There are many different compression schemes (zip, bzip, bzip2, gzip, ...), are we going to add them all ?
How much do we want to couple different parts of the system ?
I prefer to couple the compression schemes with String and ByteArray. Methods like #zipped, #unzipped are not that simple and it is not well apparent how to use that compression scheme.
Cheers, Juraj
On 25 Feb 2015, at 16:23, Juraj Kubelka <juraj.kubelka@gmail.com>
wrote:
Can I add ByteArray>>#zipped and #unzipped methods the way it is for
String? I want to compress bytes before sending through internet, for example.
Do you agree? Thanks, Juraj
Why do we have to put everything in string? why Zip string: 'hello' Zip bzip string: 'hello' Zip gzip string: 'hello' would not be more modular? Zip could be a factory and have subclasses. This is not because can extend classes that we should think about nicer way. I like for example the DateFormatter strategy related to Date from other languages because I can specify the way I want it. Stef Le 25/2/15 16:52, Juraj Kubelka a écrit :
25. 2. 2015 v 12:28, Sven Van Caekenberghe <sven@stfx.eu>:
This seems related to adding 'easy of use' methods to String.
There are many different compression schemes (zip, bzip, bzip2, gzip, ...), are we going to add them all ?
How much do we want to couple different parts of the system ? I prefer to couple the compression schemes with String and ByteArray. Methods like #zipped, #unzipped are not that simple and it is not well apparent how to use that compression scheme.
Cheers, Juraj
On 25 Feb 2015, at 16:23, Juraj Kubelka <juraj.kubelka@gmail.com> wrote:
Can I add ByteArray>>#zipped and #unzipped methods the way it is for String? I want to compress bytes before sending through internet, for example.
Do you agree? Thanks, Juraj
2015-02-26 22:37 GMT+01:00 stepharo <stepharo@free.fr>:
Why do we have to put everything in string?
why Zip string: 'hello' Zip bzip string: 'hello' Zip gzip string: 'hello'
would not be more modular? Zip could be a factory and have subclasses.
This is not because can extend classes that we should think about nicer way.
I like for example the DateFormatter strategy related to Date from other languages because I can specify the way I want it.
Stef
Because somehow you can easily pipe unary messages. ^'hello' zipped base64Encoded versus: (Encoder base64 byteArray: (Zip gzip string: 'hello')). I much much prefer to read/maintain 1st version The 2nd one looks like overkill verbiage to me.
Le 25/2/15 16:52, Juraj Kubelka a écrit :
25. 2. 2015 v 12:28, Sven Van Caekenberghe <sven@stfx.eu>:
This seems related to adding 'easy of use' methods to String.
There are many different compression schemes (zip, bzip, bzip2, gzip, ...), are we going to add them all ?
How much do we want to couple different parts of the system ?
I prefer to couple the compression schemes with String and ByteArray. Methods like #zipped, #unzipped are not that simple and it is not well apparent how to use that compression scheme.
Cheers, Juraj
On 25 Feb 2015, at 16:23, Juraj Kubelka <juraj.kubelka@gmail.com> wrote:
Can I add ByteArray>>#zipped and #unzipped methods the way it is for String? I want to compress bytes before sending through internet, for example.
Do you agree? Thanks, Juraj
Indeed, this is the primary argument for extending string. I understand it is not as nice, but I am somehow not unhappy about it. As I mentioned before, I see it as a pattern that eases embedded DSLs. But, I do agree that there is a danger of abusing this mechanism. Doru On Fri, Feb 27, 2015 at 12:21 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2015-02-26 22:37 GMT+01:00 stepharo <stepharo@free.fr>:
Why do we have to put everything in string?
why Zip string: 'hello' Zip bzip string: 'hello' Zip gzip string: 'hello'
would not be more modular? Zip could be a factory and have subclasses.
This is not because can extend classes that we should think about nicer way.
I like for example the DateFormatter strategy related to Date from other languages because I can specify the way I want it.
Stef
Because somehow you can easily pipe unary messages.
^'hello' zipped base64Encoded
versus:
(Encoder base64 byteArray: (Zip gzip string: 'hello')).
I much much prefer to read/maintain 1st version The 2nd one looks like overkill verbiage to me.
Le 25/2/15 16:52, Juraj Kubelka a écrit :
25. 2. 2015 v 12:28, Sven Van Caekenberghe <sven@stfx.eu>:
This seems related to adding 'easy of use' methods to String.
There are many different compression schemes (zip, bzip, bzip2, gzip, ...), are we going to add them all ?
How much do we want to couple different parts of the system ?
I prefer to couple the compression schemes with String and ByteArray. Methods like #zipped, #unzipped are not that simple and it is not well apparent how to use that compression scheme.
Cheers, Juraj
On 25 Feb 2015, at 16:23, Juraj Kubelka <juraj.kubelka@gmail.com>
wrote:
Can I add ByteArray>>#zipped and #unzipped methods the way it is for String? I want to compress bytes before sending through internet, for example.
Do you agree? Thanks, Juraj
-- www.tudorgirba.com "Every thing has its own flow"
participants (5)
-
Juraj Kubelka -
Nicolas Cellier -
stepharo -
Sven Van Caekenberghe -
Tudor Girba