Am Sonntag, 7. Januar 2007 22:05 schrieb Avi Alkalay: > Markus, we are having way more discussion on this subject than it deserves.
Yeah, further discussion about a different type system does not make sense until somebody came up with a solution. > 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 did not say anything against the 2 bytes they consume. My point of criticism is that it adds complexity without any prove that we have a performance issue there. And having flags for different namespaces makes it more complicate to add new namespaces, for whatever reason. > 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. "user" needs 4*8Bit = 32Bit = int Implemented correctly it take as long as checking the bit (architecture depend a bit faster or slower). > 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). If you want to have the information, if keys are already read or changed you have a problem anyway, they flag won't help you there. This information is important when upgrading the keys. e.g. debian policy says that when a maintainer changed a key to something else, and the administrator did not change it the package is allowed to overwrite the key. To be honest the concept is now for whole config files, but it will be possible to make it more fine granulate with elektra. > 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... You are fully correct with the lot of work needed to remove them ;) > I think we don't need to remove them. But we should consider not to add such features or optimizations in the future. thank you Markus Raab ------------------------------------------------------------------------- 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
