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.