# Different names for functions that do the same?

This topic is 4754 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi guys I'm trying to make my library (SDL_Config) as easy to use by end-coder as possible. Now I'm thinking whether it would be worth adding to those public API functions...

int CFG_WriteBool( /* notimportant */ );
int CFG_WriteInt( /* notimportant */ );
int CFG_WriteFloat( /* notimportant */ );
int CFG_WriteText( /* notimportant */ );


... few others, which would duplicate behaviour of those above, but would have slightly different names, ie.
                                             // Implemented in terms of:
int CFG_WriteBoolean( /* notimportant */ ); // CFG_WriteBool
int CFG_WriteInteger( /* notimportant */ ); // CFG_WriteInt
int CFG_WriteString( /* notimportant */ );  // CFG_WriteText


So, it would became non important whether you call CFG_WriteInt() or CFG_WriteInteger() - both do the same. This way, end-user could use form which he likes most, he remembers, or he actually typed. So, at last he wouldn't be forced to use functions with names, that were created in library author's sick mind :-) What do you think about it? I care, since you're the potential user of this library [wink]. Single sentence will do.

##### Share on other sites
No. It will provide slightly more code-bloat (negligible, perhaps). It will create confusion between disparate users looking at each others' code when they use two different functions to do the same thing. Consistency is a must in code that is to be distributed.

##### Share on other sites
I for one value orthogonality. Why bother adding the new functions? They don't contribute. They just serve to muddy the waters, thereby defeating the entire point of a library, which is to make everything easier.

##### Share on other sites
Look around at other popular libraries, and count how many times you see this done.
If you absolutely must do this, make sure to make the alternate names static inline functions in the header file, that merely wrap a call to the original function, as the compiler will then compile them out.

##### Share on other sites
My thoughts: Assuming that those functions actually write the type they say they do, then I'd prefer (only) the second version (or better yet just parameterize all of those so all I have to remember is CFG_Write()), and I really don't see a reason for doing this other than to create confusion down the line (I can always MACRO my own function names if I wanted to).

##### Share on other sites
Quote:
 Original post by stylin(or better yet just parameterize all of those so all I have to remember is CFG_Write())

The best idea we've heard so far.

##### Share on other sites
Quote:
Original post by TDragon
Quote:
 Original post by stylin(or better yet just parameterize all of those so all I have to remember is CFG_Write())

The best idea we've heard so far.

But SDL is written in ansi C, and C doesn't allow function overloading, so it would have to be something like void CFG_Write(void *value, uint32 length).

##### Share on other sites
Quote:
Original post by swiftcoder
Quote:
Original post by TDragon
Quote:
 Original post by stylin(or better yet just parameterize all of those so all I have to remember is CFG_Write())

The best idea we've heard so far.

But SDL is written in ansi C, and C doesn't allow function overloading, so it would have to be something like void CFG_Write(void *value, uint32 length).

The web page says C/C++, so I made an assumption.

##### Share on other sites
No, I personally don't need to have it, I wanted to introduce such functionality for the end-coder (to make his life easier). This idea came from this situation:

I was coding test program which uses SDL_Config. Everything was going fine, until I tried to compile it - several erros about "CFG_ReadInteger undeclared" appeared. I got little annoyed, since it was the way I was thinking: "I wanted to read integers", and so I misspelled CFG_ReadInt.

Then I gave a second thought to function names, especially why CFG_ReadInt is better than CFG_ReadInteger. I came to conclusion that they're equally good - so why should I discriminate people, who ie. are used to Pascal, and "integer" datatypes. So, I wanted to get best from two worlds - if you're addicted to C++ or don't like to write too much, you may use CFG_ReadInt. OTOH, if you like to use longer, more descriptive function names, and have no ambiguity whether that what you're trying to do it to read interrupt (CFG_ReadInt [wink] ), you can use CFG_ReadInteger - simple as that.

---

Hmmm, so it looks like you have some really good arguments against it (code bloat, ambiguity). Anyone else? Maybe someone is positive about this idea?

##### Share on other sites
Hmmm, good idea about that CFG_Write() thing. Though it's true that public API is written in C, there are going to be OOP wrappers after some time, when library finally matures. Then, if one will be using C++, he will have access to additional classess etc. and I'll probably add there some overloading stuff too.

1. 1
Rutin
48
2. 2
3. 3
4. 4
5. 5
JoeJ
19

• 11
• 16
• 9
• 10
• 13
• ### Forum Statistics

• Total Topics
633003
• Total Posts
3009844
• ### Who's Online (See full list)

There are no registered users currently online

×