Hi Michael, Thank you for the great feedback. I'm in the process of updating all the classes to incorporate many of your suggestions. Before I'm finished with that though, I have to tell you I'm really struggling with finding peace with the "Inheritable Default Values" approach.
On Sun, Apr 5, 2009 at 12:53 PM, Michael Sparks - spark...@gmail.com wrote: > tickmessage = True > delay = 1 > check_interval = None > def __init__(self, **argd): > super(SingleTick, self).__init__(**argd) > if self.check_interval is None or self.check_interval > self.delay: > self.check_interval = self.delay ... > > * Use of class attributes to provide default values, and enabling the > **argd code to override the default values. > - cf http://www.kamaelia.org/InheritableDefaultValues First let me say that I read that link before my first submission and chose not to go that way because I didn't feel comfortable with it. After your feedback, I went back and re-read the wiki entry several more times. I'm feeling more comfortable, but there's still some reluctance. If possible, I'd like you to try to help me understand how to use this more comfortably. The most obvious problem I have with this approach is what you've already admitted is the major downside. You lose the self-documenting nature of the __init__ routines. If I have to go to the extra trouble to document these optional[*] parameters, where is this best place to do that? The class docstring? The init method docstring? Notice my [*] on the word optional? That is the second and more philosophical problem I have with the "Inheritable Default Values" approach. The name of the approach implies to me that we are going to use "inheritance" for "default value" parameters. And parameters that have default values are what I call optional. But, your wiki entry shows using this approach for ALL parameters; in effect making all parameters optional. And this really sticks in my craw. Closely related to that pain is what I see in your wiki entry of conflating two different scenarios: subclassing and factory functions. First let me address the "all parameters are optional" pain. I have found peace with using this "inheritance" method for limited decoupling of honestly optional parameters for the purposes of subclassing. Let's take my simple class SingleTick. Normally init would take 3 parameters: a delay, a tick_mesg, and check_interval. To me, it makes perfect sense to make the tick_mesg and check_interval optional as there are sensible defaults. But the delay parameter should IMO be required. It doesn't make sense to me to provide a default nor to decouple future subclasses from that core parameter. What message to send, how often to check for early termination, maybe a callback(?) for early termination - those kind of things seem nebulous enough to warrant the "inheritance" method. So I would suggest an init signature of: tick_mesg = True check_interval = None __init__(self, delay, **kwargs) But I don't think it makes sense to move delay into the **kwargs as well. And in your wiki example, I think the port and protocol parameters falls in this same category. It seems like those should be non-optional arguments broken out of more flexible parameters like socket options. While keeping basic necessary core parameters as non-optional does add slightly to the typing for factory functions, I don't think it's an unreasonable trade-off to stay in line with the principle of "explicit is better than implicit". And while more esoteric parameters might change over time, I don't see a major risk is coupling those fundamentally required parameters. To boil it down, I can see this approach useful for optional parameters with defaults, but I think it sacrifices too much clarity for negligible gain when used for fundamentally necessary parameters. That said, it seems you came to a different internal equilibrium and I would really appreciate it if you could help me see it from your perspective. Thanks, Steve --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@googlegroups.com To unsubscribe from this group, send email to kamaelia+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/kamaelia?hl=en -~----------~----~----~----~------~----~------~--~---
