easy to answer that .... initialize their values , make sure you use sensible names for the dictionary entries. documented and still no image pollution.
On Fri, Dec 11, 2015 at 8:02 PM Sven Van Caekenberghe <[email protected]> wrote: > > > 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. > > >
