Why Zinc servers implemented with options dictionary instead of normal instance variables?
Hello. Just looked on ZnServer code. And I was wondering when see that everything is stored inside "options" variable (which is dictionary). For example port number is option which is really strange. What the reason for that?
Because there are many options, 10, 20, and at that time slots were not yet available. It also makes it easier/clearer to treat them consistently.
On 11 Dec 2015, at 15:46, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hello.
Just looked on ZnServer code. And I was wondering when see that everything is stored inside "options" variable (which is dictionary). For example port number is option which is really strange.
What the reason for that?
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.
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. 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.
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.
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 <sven@stfx.eu> wrote:
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.
participants (3)
-
Denis Kudriashov -
Dimitris Chloupis -
Sven Van Caekenberghe