Re-working GNCId: removing GNCIdType enum

[Dave Peticolas]

--=-arqW14i7CDI2cLGTCoo9
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sat, 2001-11-24 at 16:19, Derek Atkins wrote:
> Ok, strings it is, then.  Do you have a proposal for how to
> handle the various 	switch (type_id) { }   cases throughout
> the code?  In particular, there are major switches in:
>=20
> app-utils/gnc-component-manager.c

Here we would need a hash table for the event masks,
and the code would need to be generalized to all the
types and not just accounts & transactions (that needs
to be done anyway).


> backend/postgres/events.c

This one is complicated, we would have to make a general
mechanism for detection events for the other, newer types.
This would probably need to be part of the backend extension
mechanism.


> backend/postgres/gncquery.c

Here I'm not sure using other types besided
accounts, transactions, and splits would
make sense, unless guid Queries are extended
to handle new types.


> engine/Query.c

Same as above. If you want to extend the GUID predicates,
a dynamic hash of predicates would be needed. Otherwise,
a static hash for just the types used now would probably
be fine. Keep in mind that Queries right now are mainly
for finding Splits & Transactions. If we want to make them
general, we need a lot more, as you & Linas have been
discussing.


> gnome/top-level.c

This code is supposed to bring up an appropriate register
given the type of the guid. For most of the newer types it
probably would not make much sense.

Of the above, the component manager, the Query.c, and possibly
the events code would be performance-impacted by lots of strcmp
operations.

dave


--=-arqW14i7CDI2cLGTCoo9
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA8AED05effKKCmfpIRAkUsAKDofABC35zqPdJMjHJwAAXalkYCfwCfTusE
M6+PT7xhumQd4cHX1dmERZo=
=5KA5
-----END PGP SIGNATURE-----

--=-arqW14i7CDI2cLGTCoo9--