Attribute handling (was: Re: [devel] API changes proposed)

[Sven Herzberg]

Am Mittwoch, den 16.03.2005, 08:05 -0300 schrieb eazel7:
> On Wed, 16 Mar 2005 09:36:21 +0100, Sven Herzberg <address@hidden> wrote:
> > Am Samstag, den 05.03.2005, 22:05 -0300 schrieb Ezequiel Pérez:
> > > · The comparission block/whatever <> template attributes can't set
> > > permanent changes in an attribute independent from the template, I think
> > > it'd be better an cria_block_is_set (CriaBlockAttribute attribute)
> > > function being CriaBlockAttribute an enum and adding in the CriaBlock
> > > private structure an boolean array for with the setted values of those
> > > attributes. - A decission at this point would help me to do not code
> > > twice the writer
> > 
> >   Please suggest some API and not just "this need to change". I fell
> > very uncomfortable with your idea of having an "is_set" function for
> > each attribute.
> there is just one is_set function, not one for each attribute.
> I'm not watching the code right now, but this would give you an idea
> of what I mean:
> 
> typedef enum {
>   CRIA_BLOCK_COLOR,
>   CRIA_BLOCK_FONT_FAMILY,
>   CRIA_BLOCK_FONT_BOLD,
>   CRIA_BLOCK_BG_COLOR,
>   CRIA_BLOCK_BORDER_WIDTH,
>   CRIA_BLOCK_BORDER_COLOR,
>   CRIA_BLOCK_LAST_ATTR
> } CriaBlockAttribute;
> // and etcetera
> 
> typedef struct {
> //...
>   gboolean set_attr[CRIA_BLOCK_LAST_ATTR];
> //...
> } CriaBlock;
> 
> //this function to know if the value is set specifically for that element, 
> //if not it shouldn't be written to the specific block source
> //on the xml (or whatever be the format)
> gboolean
> cria_block_is_set (CriaBlock *block, CriaBlockAttribute attr)
> {
>   return block->set_attr[attr];
> }
> 
> //this function to set/unset the attribute when setting it's
> //attr specifically for that block or taking it from the tamplate
> void
> cria_block_set_attr (CriaBlock *block, CriaBlockAttribute attr, gboolean val)
> {
>   block->set_attr[attr] = val;
> }
> 
> there's no need to write more than one is_set function

  This is very static and we would have problems to extend this scheme
easily as it would mean to extend the enumeration, recompile the whole
application (just because the size of the enumeration and the arrays
changed).

  The other disadvantage is waste of memory: I promise, you don't want
to have the whole array AND the formatting information stored in memory
for EACH structure (given my current presentations this would result in
about 80 arrays of which none would be used).

  So, as long as won't get a dynamic structure for this, I won't accept
it, because there are still lots of machines with a lot few memory than
(eg.) mines. We should only store information that we need.

  The main problem we need to fix is to have a dynamic structure that
keeps the formatting information and that provides information about
whether or not an attribute is set.

Regards,
  Sven
-- 
Sven Herzberg <address@hidden>    · GNOME Deutschland <www.gnome.de>
Jabber <address@hidden>         · ICQ <177176642>
GnuPG <F020 B158 2696 6D6A 2870 F53C 0565 FD6B B1C3 0AFE>
Criawips <www.nongnu.org/criawips>· GnomeGCJ <gnome-gcj.sourceforge.net>

signature.asc
Description: This is a digitally signed message part