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"