On 28 Jun 2012, at 02:55, Gregory Casamento wrote: > Fred, > > What I had thought is that the initializeBackend method could use information > from the info.plist for the bundle to determine what the concrete subclass > for the context and server are. This would be trivial to implement. > > It seems to me that it should be possible to compile a backend without > modifying the logic I quoted in the previous message. > > Wouldn't it be also better to build the common parts of the backend into a > framework so that "third party" backends could be written without requiring > direct changes to GNUstep code. > > This is just something I was thinking about that could be useful which is why > I asked for thoughts regarding it. It is not a fully formed idea, so there > shouldn't be any puzzling over it, I was asking people to brainstorm a little > with me.
I agree that it would be quite nice (in the sense that it feels more elegant/pleasing) to have the backend class determined automatically without having to set a user default. Another option would be to remove the GSBackend.m source, and have it generated automatically when you build a backend ... then the GSBackend +initialize method would be different for each backend and would initialize the correct classes. We could also abolish all these separate names for the context class and just use a single name (as I understand it, a backend bundle only contains one fo the context classes anyway. Or we could add a [GSBackend+contextClass] method to return the correct context, and backend developers would just override that in a category. That being said , as Fred points out, all this is *in* the backend source ... so any third party writing a new backend can set it up any way they like anyway and wouldn't be modifying any gnustep code (they'd be replacing the gnustep backend code with their own). Of course, you are also right that minimising the work people would need to do is a good idea, but that probably means wholesale restructuring to try and extract common functionality _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
