Re: EIEIO version of BBDB
Eric Abrahamsen writes: > "Roland Winkler" writes: > >> On Thu Dec 24 2015 Eric Abrahamsen wrote: >>> A while ago there was a very brief exchange about the possibility of a >>> version of BBDB refactored on top of the EIEIO object orientation >>> library. I've been thinking about that for a while, and recently wrote >>> a sort of prototype. I'd like to share it with everyone, either as an >>> attachment to the list, or I guess preferably by pushing a branch to >>> the git repo. >>> >>> There isn't anything particularly wrong with BBDB that needs fixing, >>> but an OO version of the database does lots of good things, mostly in >>> the direction of extension and customization. It also gets us free >>> file serialization courtesy of eieio-persistent, and I've added in >>> support for multiple databases. Anyhoo, I'm going to post the code sketch as it stands for anyone who's interested in looking: https://ericabrahamsen.net/bbdb-eieio.el The file requires bbdb, but also clobbers some of its functions. It's best to start an "emacs -Q", make sure BBDB proper is on the load path, then require the above file. Then it's `bbdb-load' to start things off, and `bbdb-create-record' to make records (try it with and without a prefix arg). Once there are a few records, take a look at the `bbdb-record-tracker' variable, as well as `bbdb-db-list', then call `bbdb-save' to save. Most of the work has gone into maintaining integrity when there are multiple databases, and when records can be moved between databases. It's even possible to have single records stored in more than one database -- duplicates are identified by uuid and merged. I'll probably just continue pottering with this slowly. E -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 ___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
Re: EIEIO version of BBDB
"Roland Winkler" writes: > On Thu Dec 24 2015 Eric Abrahamsen wrote: >> A while ago there was a very brief exchange about the possibility of a >> version of BBDB refactored on top of the EIEIO object orientation >> library. I've been thinking about that for a while, and recently wrote >> a sort of prototype. I'd like to share it with everyone, either as an >> attachment to the list, or I guess preferably by pushing a branch to >> the git repo. >> >> There isn't anything particularly wrong with BBDB that needs fixing, >> but an OO version of the database does lots of good things, mostly in >> the direction of extension and customization. It also gets us free >> file serialization courtesy of eieio-persistent, and I've added in >> support for multiple databases. > > I don't know much about EIEIO, but I am not sure it would benefit > BBDB so much to add an extra layer of abstraction. Correct me if I > am wrong, but what kind of problem can really be solved cleaner and > how? It's not really about abstraction, but the way that classes and methods are modular, and "pluggable". Some examples below. > Extensions and customizations of BBDB should use a high-level API, > which does not expose the details of how things are implemented. > Currently, a good example for this is the function > bbdb-record-set-field. Anyone wanting to extend or customize BBDB > should not call the low-level functions that do the real work inside > bbdb-record-set-field, because the low-level implementation might > change at some point for whatever reason. How could EIEIO possibly > provide a better solution (better in what sense)? Extension/customization would be a result not of exposing BBDB's inner workings, but of making database/record/field classes responsible for their own behavior, and allowing external code to replace or alter that behavior. For example, adding a new field to a record. What the code does is pick up the current record, then prompt the user for the field class to insert. Then it passes the field class to the record's `bbdb-record-insert-field' method. The record itself decides if it can accept this field. If it can, the record calls the field class's `bbdb-read' method, which prompts the user for values, and returns an actual field object. The record then puts this object in the appropriate slot, and calls a method on its database to let it know it's done. All this happens in methods belonging to the various classes. Users have customization options saying what default classes they want to use -- they can change the behavior by changing the default classes. Or they can load libraries that override the basic methods, changing behavior without having to change any of BBDB's internal code, or their own init options. I've tried to set it up this way for most aspects of BBDB's internal behavior: The classes themselves are responsible for creation/set-up, deletion/tear-down, "noticing"... In other words, the API we're "exposing" to developers isn't BBDB's internals at all, but the method signatures of the various classes. Other possibilities: 1. Funky database subclasses. A database backend that reads from/writes to a VCARD file, or a remote CardDav server. These backends would be a lot of work to write, obviously, but they could be written and plugged in without having to modify the existing codebase at all. 2. A "more international" BBDB. Users load an additional library, say "bbdb-i18n.el", containing new `bbdb-read' and `bbdb-display' methods for the name, phone and address field classes that are more internationally aware. For instance, when a phone field is created, it would first prompt for a country name. The country code would then be automatically added, and the phone number displayed in the proper format for that country. A Hong Kong address would not ask you for a postcode. Etc. From the user's point of view, all they had to do was (require 'bbdb-i18n). 3. Newer versions of EIEIO support dispatch on multiple arguments, and dispatch using `eql'. That means field display could be completely modular. For instance, the way a phone field displays in the one-line format is a method with this signature: (cl-defmethod bbdb-display ((field bbdb-field-phone) (format (eql one-line Overriding these methods would provide very fine-grained control over how the BBDB buffer looks. You could even register a new display symbol and write your own display routine. I definitely understand the wariness over letting people run amok in the guts of BBDB. But the great thing about generic functions is that you can just load them on top of existing code, either replacing or augmenting it. A last example of customizability: I live and work in China, and have a lot of Chinese contacts. If someone is surnamed 周 and named 丽华, I usually add the romanization of this name as an aka: "Zhou Lihua", so that I don't have to switch input methods to search/complete with
Re: EIEIO version of BBDB
On Thu Dec 24 2015 Eric Abrahamsen wrote: > A while ago there was a very brief exchange about the possibility of a > version of BBDB refactored on top of the EIEIO object orientation > library. I've been thinking about that for a while, and recently wrote > a sort of prototype. I'd like to share it with everyone, either as an > attachment to the list, or I guess preferably by pushing a branch to > the git repo. > > There isn't anything particularly wrong with BBDB that needs fixing, > but an OO version of the database does lots of good things, mostly in > the direction of extension and customization. It also gets us free > file serialization courtesy of eieio-persistent, and I've added in > support for multiple databases. I don't know much about EIEIO, but I am not sure it would benefit BBDB so much to add an extra layer of abstraction. Correct me if I am wrong, but what kind of problem can really be solved cleaner and how? Extensions and customizations of BBDB should use a high-level API, which does not expose the details of how things are implemented. Currently, a good example for this is the function bbdb-record-set-field. Anyone wanting to extend or customize BBDB should not call the low-level functions that do the real work inside bbdb-record-set-field, because the low-level implementation might change at some point for whatever reason. How could EIEIO possibly provide a better solution (better in what sense)? Apart from that, I also believe that currently there are more important issues. First of all, I hope that with the OK from RMS, we can now integrate the core of BBDB into GNU Emacs (which still requires some work to make it happen). Roland -- ___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
EIEIO version of BBDB
And while we're all here... A while ago there was a very brief exchange about the possibility of a version of BBDB refactored on top of the EIEIO object orientation library. I've been thinking about that for a while, and recently wrote a sort of prototype. I'd like to share it with everyone, either as an attachment to the list, or I guess preferably by pushing a branch to the git repo. There isn't anything particularly wrong with BBDB that needs fixing, but an OO version of the database does lots of good things, mostly in the direction of extension and customization. It also gets us free file serialization courtesy of eieio-persistent, and I've added in support for multiple databases. One semi-serious problem is that EIEIO is under development, and a bit of a moving target. This version of BBDB would likely only reliably work with a development version of Emacs. But if we're considering bundling BBDB with Emacs anyway, that might be okay. Right now it's kind of a code sketch. You can load it, and it works fine in an IELM session, it's just very rudimentary. Basically I put in enough effort that it can serve as the basis for a design discussion, but not so much that I would feel bad about dumping large parts of the code, or scrapping it altogether. Anyway, if there's interest, I can push a branch or something... Thanks, Eric -- ___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/