Re: EIEIO version of BBDB

[Eric Abrahamsen]

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=/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]

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/

Re: EIEIO version of BBDB

[Eric Abrahamsen]

"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 

EIEIO version of BBDB

[Eric Abrahamsen]

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/