Design advice

[Carl Youngblood]

I'm in the process of writing a ruby version of perl's Palm:DB
family, which allows you to write and read Palm database (PDB) files
for a number of Palm OS applications like Phone Book, ToDo, Datebook
etc.

FYI, documentation of Palm:DB is here:

http://aspn.activestate.com/ASPN/CodeDoc/p5-Palm/Palm/PDB.html

PDB files have a generic header format and hold one or more records,
each of which is in an application-specific format.

The approach of perl's Palm:DB is to create an abstract record
handler class and create a new child of the record handler class for
each application. The Palm:DB class calls the record-handling
functions of whatever handler the programmer includes.

I'm debating between this approach, and simply creating a parent PDB
class with empty functions for handling records and creating
descendents of this parent class with filled-in methods for record
handling as well as application-specific methods.

Any suggestions?

Thanks,

Carl Youngblood

 

[Zachary P. Landau]

--TRYliJ5NKNqkz5bu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

The approach of perl's Palm:DB is to create an abstract record
handler class and create a new child of the record handler class for
each application. The Palm:DB class calls the record-handling
functions of whatever handler the programmer includes.
=20
I'm debating between this approach, and simply creating a parent PDB
class with empty functions for handling records and creating
descendents of this parent class with filled-in methods for record
handling as well as application-specific methods.
=20
Any suggestions?

I would probably go with the second option, just because that method is
used more often and is more traditional. But I don't really think there
is much of a difference in the end.

Good luck with the project, I'll definitely be interested in using it
once you have it finished.

--
Zachary P. Landau <[email protected]>
GPG: gpg --recv-key 0x24E5AD99 | http://kapheine.hypa.net/kapheine.asc

--TRYliJ5NKNqkz5bu
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBMTBUCwWyMCTlrZkRApTdAJ90D5krvdukgkfefnuiEsA59g4BPwCeKQHZ
py6YzJMnivalj5PgusQFH+o=
=Ria/
-----END PGP SIGNATURE-----

--TRYliJ5NKNqkz5bu--

 

[Robert Klemme]

I'm in the process of writing a ruby version of perl's Palm:DB
family, which allows you to write and read Palm database (PDB) files
for a number of Palm OS applications like Phone Book, ToDo, Datebook
etc.

FYI, documentation of Palm:DB is here:

http://aspn.activestate.com/ASPN/CodeDoc/p5-Palm/Palm/PDB.html

PDB files have a generic header format and hold one or more records,
each of which is in an application-specific format.

The approach of perl's Palm:DB is to create an abstract record
handler class and create a new child of the record handler class for
each application. The Palm:DB class calls the record-handling
functions of whatever handler the programmer includes.

I'm debating between this approach, and simply creating a parent PDB
class with empty functions for handling records and creating
descendents of this parent class with filled-in methods for record
handling as well as application-specific methods.

I'd follow the perl pattern: If I understood correctly, the base class has
all the functionality that's common to all applications (i.e. opening,
closing, reading the header and generic record reading methods). Sub
classes then need to add only the application specific stuff. (Maybe #each
for each record or somthing similar; in that case the base class cound mixin
Enumerable.)

An alternative would be to use delegation, i.e. have a single class that
does all the low level stuff and a class for each application that provides
application specific code and interface. But I rather tend to the first
approach as it seems to me that some of the base class functions will be
invoked by clients (i.e. reading header info or so) - that makes delegation
ugly because then you'll have some / a lot methods that simply delegate.

Additional remark: this might lend to a transaction like behavior with a
class method open() that yields a sub class instance (if it's possible to
determine the sub class from all infos provided by open).

module PDB
class DB
def self.open(file, mode)
db = ( case file
when /.dat/
DbDatabase
....
).new(file, mode)

begin
yield db
ensure
db.close
end
end
end
end

Then

PDB:B.open("foo") do |db|
db.each do |record|
p record
end
end


Kind regards

robert