"Roland Winkler" <wink...@gnu.org> 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 this
contact. That's extra work, and data duplication.
With this class system, I could put something like the following in my
init files:
#+BEGIN_SRC elisp
(with-eval-after-load 'bbdb
(cl-defmethod bbdb-init :after ((name bbdb-field-name) &optional record)
(let ((namestring (bbdb-string name))
(roman
(when (string-match-p "\\`\cc+" namestring)
(make-pinyin-roman namestring))))
(when (and roman record)
(bbdb-puthash roman record)))))
#+END_SRC
The `bbdb-init' method runs when the name object is loaded, created, or
edited. If the name is in Chinese, the function `make-pinyin-roman'
takes the characters and turns them into roman letters (I already have
this function), and then hashes the record against the romanization. Now
I can search/complete against the contact's romanized name, without
having to do any extra work.
If later I develop that package further, with more Chinese-based stuff
in it, I could stick it on Elpa and let other people install it.
> 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).
Fair enough! Out of curiosity, what sort of things have to happen?
Sorry for the enormous message. I also recognize that no one asked me to
do this, and it might be a little presumptuous! But I do think it could
really open things up both for third-party developers, and regular
users.
Eric
------------------------------------------------------------------------------
_______________________________________________
bbdb-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bbdb-info
BBDB Home Page: http://bbdb.sourceforge.net/
