[EMAIL PROTECTED] wrote: >>> 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
Right. I initially thought some of the methods might be called from outside the class but since none are, I'll access the class variables directly. > 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. > Yes me too especially before I send out what is hopefully the last webrev. ;-) Tim > -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
