[placement][ptg] code refactoring constraints and goals

Eric Fried openstack at fried.cc
Thu Apr 11 18:22:08 UTC 2019


>> (1) Pass `self` to the db method. This grates on me pretty bad. It
>> screams that the thing should be an instance method.
> 
> That is actually a pretty old design pattern: passing a data object, rather than a slew of parameters. Of course, it would be cleaner to keep them as instance methods, and that would be my preference. I know that you have expressed an interest in reducing the overall size of the individual modules, so this option is only valid if smaller modules is decided on as a Good Thing™, 

Smaller modules would be nice, but I'm pretty soft on that since earlier
in this thread (though I wouldn't want resource_provider.py getting any
bigger than it is today).

I thought the motivator here was separation/isolation of the db-ish
methods into their own space.

Looking at resource_provider.py specifically, many of the existing
module-level @db_api methods today accept a ResourceProvider as a
parameter. So for the sake of consistency, we should either make those
into instance methods, or move all the existing @db_api instance methods
to the module level (be it this module or a different one).

Which I think is more or less where we started. I was ready to be happy
with the idea of moving the @db_api methods into their own space until I
saw that we would need to pass `self` around. If there's a consensus
that that's okay, I'll get over it (and maybe even do the work).

Jay, you had expressed in favor of the other suggestion (group methods
"intuitively" in the ResourceProvider class, even @db_api ones) before
we really opened up this one (move @db_api methods into their own space,
even though that means passing `self` to them). What's your preference
at this point?

efried
.




More information about the openstack-discuss mailing list