1. naming convention
- Posted by jacques deschênes <desja at g?obetrott?r.net> Apr 17, 2008
- 571 views
- Last edited Apr 18, 2008
As we are talking about a standard library, it is the occasion to introduce some naming convention that would reduce naming clash. The idea of making it as short as possible for the economy of some keystrokes is not a good idea at the end. A look at what is done with other project could be inspiring. for exemple the gtk project prefix all global with library name like: gtk_ glib_ etc Jacques Deschênes
2. Re: naming convention
- Posted by Jeremy Cowgar <jeremy at c?wgar.c?m> Apr 17, 2008
- 546 views
- Last edited Apr 18, 2008
jacques deschênes wrote: > > As we are talking about a standard library, it is the occasion to introduce > some naming convention that would reduce naming clash. The idea of making it > as short as possible for the economy of some keystrokes is not a good idea at > the end. > A look at what is done with other project could be inspiring. > > for exemple the gtk project prefix all global with library name like: > gtk_ > glib_ > etc I'm not quite sure I follow. Can you expand a bit? I too dislike cryptic names but also dislike string_split_by_char("John Doe", " "). I would strive for a happy medium, but I am open to suggestions. The current functions are all lower case and separated by an underscore where needed. I was going to follow suite but I do not think that's what your speaking of. -- Jeremy Cowgar http://jeremy.cowgar.com
3. Re: naming convention
- Posted by Matt Lewis <matthewwalkerlewis at gmail.c??> Apr 17, 2008
- 557 views
- Last edited Apr 18, 2008
jacques deschênes wrote: > > As we are talking about a standard library, it is the occasion to introduce > some naming convention that would reduce naming clash. The idea of making it > as short as possible for the economy of some keystrokes is not a good idea at > the end. > A look at what is done with other project could be inspiring. > > for exemple the gtk project prefix all global with library name like: > gtk_ > glib_ > etc I disagree. I think that the namespace and general conflict resolution in the next version of euphoria is much more useful, and will handle this sort of thing much better. Matt
4. Re: naming convention
- Posted by Aku <akusaya at g?x.net> Apr 18, 2008
- 552 views
Jeremy Cowgar wrote: > I'm not quite sure I follow. Can you expand a bit? I too dislike cryptic names > but also dislike string_split_by_char("John Doe", " "). I would strive for a > happy medium, but I am open to suggestions. The current functions are all > lower > case and separated by an underscore where needed. I was going to follow suite > but I do not think that's what your speaking of. Just my 0.02 cents (that's 0.0002$), In my own Eu projects, because Eu do not have a neat namespace feature, I usually named my function with combination of _ and camelCase. So, if I were to make replace all function for strings library, I will use a name like str_replaceAll instead of replaceAll or replace_all or str_replace_all. Then str_indexOf, str_lastIndexOf. The same goes for hash, math, dll, struct, date etc. Like hash_put, date_getSecond, etc. How if we follow Java API for those standard packages? (vector, hash, set, date, pattern (regex), etc) I think Java API is tested by time and by users, and the design is quite great. When I create Eu program now, I almost always use my standard include file. Unfortunately not every people wants to write their own standard include file.
5. Re: naming convention
- Posted by jacques deschênes <desja at globetrott?r.ne?> Apr 19, 2008
- 563 views
Yes it is what I meant in my comment, I like that style. its no more trouble than the use of: incluse string.e as str str:foo() Reading the code one knows from which library the identifier come from and at the same it tell the nature of data object on which it work. for exemple str_split() tel us that it is from string library and at the same we knows that it work on string. The more a function name tell about itself the less one need to comment is code. Jacques Deschênes Aku wrote: > > Jeremy Cowgar wrote: > > I'm not quite sure I follow. Can you expand a bit? I too dislike cryptic > > names > > but also dislike string_split_by_char("John Doe", " "). I would strive for a > > happy medium, but I am open to suggestions. The current functions are all > > lower > > case and separated by an underscore where needed. I was going to follow > > suite > > but I do not think that's what your speaking of. > > Just my 0.02 cents (that's 0.0002$), > > In my own Eu projects, because Eu do not have a neat namespace feature, > I usually named my function with combination of _ and camelCase. > > So, if I were to make replace all function for strings library, I will use > a name like str_replaceAll instead of replaceAll or replace_all or > str_replace_all. Then str_indexOf, str_lastIndexOf. The same goes for hash, > > math, dll, struct, date etc. Like hash_put, date_getSecond, etc. > > How if we follow Java API for those standard packages? (vector, hash, > set, date, pattern (regex), etc) I think Java API is tested by time and by > users, and the design is quite great. > > When I create Eu program now, I almost always use my standard include file. > > Unfortunately not every people wants to write their own standard include file.