> > It took me a minute to figure this out. The way this is implemented is > > kindof sneaky. I had to notice that every function starts with a call > > OK maybe sneaky, but the intent wasn't to be.
Not accusing you of malicious intent. :) > > to get_env() and get_env() checks is_BEenv. It might just be easier to > > check is_BEenv directly inside the methods. There are a couple of other > > possible approaches too: > > Yeah I wasn't sure what the OO convention was, wrap a variable in a > method or just access it directly. If it is most conventional to > access the member directly I'll do that. My take is that if you're the class, it's okay to access the variable directly. If you're outside the class, you may want to use the accessor function. Python has some additional functionality that lets you do neat things here, but I don't know if any of that is applicable. > > 1. Create an abstract BootEnv class, define BootEnvZFS and BootEnvNull > > classes. When we can import libbe, use the BootEnvZFS class, otherwise > > use the BootEnvNull class. Presumably, the null class has methods that > > don't actually do any work. > > > > You could also just make the parent class have null methods, and then > > have BootEnvZFS do work. There are a few different ways you could go > > with this general idea. Stephen/Danek may want to say more about this, > > too. > > Each of these are great ideas but wouldn't the first one create > duplicate code? Not exactly. The idea would be that you have the same methods defined for each class, but only BootEnvZFS would contain code that does any work. I like the progress that we're making and I'd like to get a couple of other reviewers to sign off on your wad too. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
