> On 11 Dec 2015, at 17:45, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
>
> the real question here is why pharo classes have the tendency to output so much data through individual methods when a single method returning a dictionary or any other collection would make much more sense and would be far more flexible and elegant to deal with. Unnecessary pollution of the image with methods.

Hmm, I wouldn't call that pollution. I think it is a form of documentation. The options are a good example of that. We could add an accessor for #options, just returning the dictionary that is now encapsulated, and then delete all the nice accessors, like #useGzipCompressionAndChunking. With the accessors gone, how would you discover or see what is available ? Where should the existing options be documented ? Now you can browse them in the options protocol, all in one place, one by one, with documentation and clearly visible defaults.

> On Fri, Dec 11, 2015 at 6:11 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
>
> > On 11 Dec 2015, at 16:28, Denis Kudriashov <dionisiydk@gmail.com> wrote:
> >
> >
> > 2015-12-11 15:51 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:
> > Because there are many options, 10, 20, and at that time slots were not yet available.
> >
> > Is not it is same case as class with 20 variables which always smell bad?
>
> That's why it is a dictionary ;-)
>
> Can't an object have 10, 20 or more properties (independent of how they are stored) ?
>
> You could of course delegate options to another sub object but why ?
>
> Apart from that, I do agree that both the main server object and the main client object are too big, they are like big interfaces to a lot of related functionality. The objects behind them, the ones in Zinc-HTTP-Core, are much more single purpose and simpler.