From: Doug B. <dou...@gm...> - 2013-12-29 21:02:49
|
On Sun, Dec 29, 2013 at 1:45 PM, Nick Hall <nic...@ho...> wrote: > On 27/12/13 23:47, Doug Blank wrote: >>> >>> The proposed changes save typing, but I don't see much of an advantage. >> >> Yes, these two are only about saving typing. I think about how often I >> type "_from_handle" and "_from_gramps_id" and how many more times I >> will type them in the future.... But I think "get_person_from_id" and >> just "get_person" are clear and consistent too, so all things being >> equal, why not be efficient? > > > If you want to be efficient then we should make a bigger change. Consider > the following code: > > handle = family.get_father_handle() > if handle: > father = db.get_person_from_handle(handle) > > What we really want is: > > father = family.get_father() > > We could also tidy up some of the utility functions. For example: > > event.get_participants() > > would be nicer than: > > get_participant_from_event(db, event.handle) > > Why do we expose the database handle in the API? > > Perhaps we need to think about a gen.api module? This could also > incorporate the best ideas in the simple database access module. Yes, I think that another layer that hides gen.lib and handle, but builds on gen.lib, is a great idea, and not just for efficiency of typing. Currently, we expose the (what should be internal) handles because that is the only way to write code that can get the parents given a family object. But we write that code over and over again. We really do need a more abstract API. If we introduce that layer, then we could gain a lot more than just another API... we could gain database independence by using an API that allows us to talk to a variety of backends, and some well-tested code that we only write once. Thinking ahead, if we wanted a new API to subsume the old gen.lib objects, then we might not want to clean up the old gen.lib method names if there was a chance that new names might clash with a new abstraction layer. Of course, we have control over both interfaces, but if we went with, say, Django's abstraction layer, then a few things are fixed. But there are probably good reasons to make new objects independent of the old ones. So, I think we can focus on the clean up of the gen.lib methods independent of a new layer. -Doug > Regards, > > > Nick. > |