Markus, we are having way more discussion on this subject than it deserves.
Your comments are reasonable some how, but the computational cost for it all
is almost zero. Flags in the Key structure take 2 bytes, and some methods
use it for control, sometimes to get some good performance improvements.
I would say that keyIsUser() and keyIsSystem() are the ones that take most
advantages from flags. They are called a lot of times, and they use flags to
avoid expensive string comparations.
Flags don't go to storage. They are volatile (one more reason to not worry
about them). And they are for internal use only.
Except the one for keyGetFlag() and keySetFlag(), which is also volatile,
and have no semantics for the library, only for the user. If you use GMail,
you can see that each message has a star you can highlight or not. This star
has no meaning to the mail system, only to the user. The same for this flag.
This is a useful programming paradigm and keyNew() uses it (check doxy).
Flags are currently very well integrated into the library, are useful, their
semantics are correct, and to remove them will cost a lot of work and will
make several methods slower. To save only 2 bytes...
I think we don't need to remove them.
Regards,
Avi
On 1/5/07, Markus Raab <[EMAIL PROTECTED]> wrote:
2. Januar 2007 02:18 Avi Alkalay wrote:
> On 12/29/06, Markus Raab <[EMAIL PROTECTED]> wrote:
> > > int keyIsUser(const Key *key) {
> > > return (key->flags & KEY_SWITCH_ISUSER)?1:0;
> > > }
> >
> > yeah, but why not implementing it with return
keyIsNameUser(key->key);?
>
> Because they have different purposes.
> keyIsUser() is cheap because it only compares bits, and is used on Key
> objects.
> keyNameIsUser() is much more expansive because it compares strings, if
you
> have them.
Its an not trivial (means you can forget to set the flag at some place)
optimization for a part which is *really* not performance-critical. Such
things should not be done in the state we are now.
> No, there is no useful case until we have a opposite example. I know the
>
> > documentation. Its not cheap, you have to maintain that useless flag
in
> > every
> > backend.
>
> No. The flag is only maintained in the higher level API. I can't see
where
> in backends they are used.
Now you really fall into the trap :-)
Flag has two meanings in elektra:
- the flags for sync key and some useless optimizations
- the flag which can be set by keySetFlag()
The second flag has of course be set by the backend, otherwise you would
have
the funny beheavior:
keySetFlag (key);
kdbSetKey (h, key);
kdbGetKey (h, key);
if (keyGetFlag(key) == 0) printf ("elektra is very weird");
Elektra really should not be weird :-)
The only rational solution can be removing the flag nobody knows what it
is
for.
> There is no clear semantic defined which information must be stored by
the
>
> > backend anyway.
>
> Then maybe documentation must be improved, and not code.
> Backends can store the information they want in the private backend
data.
> The only thing that matters is that they must fulfill the API
definitions,
> which is described at
http://www.libelektra.org/elektra-api/group__kdb.html
Yeah, I fully agree.
The documentation must really make clear what behavior you are going to
expect. Test cases under /tests must verify the correctness.
thank you
Markus Raab
--
http://avi.alkalay.net/blog
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Registry-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/registry-list
