> On 11 Dec 2015, at 17:45, Dimitris Chloupis <[email protected]> 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 <[email protected]> wrote: > > > On 11 Dec 2015, at 16:28, Denis Kudriashov <[email protected]> wrote: > > > > > > 2015-12-11 15:51 GMT+01:00 Sven Van Caekenberghe <[email protected]>: > > 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.
