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"