Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(In)Consistent API Naming #65

Open
AerialX opened this issue Jan 14, 2011 · 7 comments
Open

(In)Consistent API Naming #65

AerialX opened this issue Jan 14, 2011 · 7 comments

Comments

@AerialX
Copy link
Member

AerialX commented Jan 14, 2011

We don't have any set rules and it's getting to be kinda random. We need to decide on a standard set of rules and put them up somewhere like on a wiki page. Then rename psl1ght's functions accordingly.

@AerialX
Copy link
Member Author

AerialX commented Jan 14, 2011

Here are my personal thoughts/suggestions, which I've generally been trying to follow:

Functions go like libnameFunctionName(int mixedCaseArgs);

Types are named with LibnameFullCase. Structs are always typedef'd anonymous structs. Struct member names are also lowerMixedCase. And then constants/enums LIBNAME_CATEGORY_ETC.

And headers belong in include/libname/modulename.h, the exception to this being that liblv2 goes in include/lv2, but its function names are prefixed with sysEtc rather than lv2Etc, since the lv2 prefix is taken by include/psl1ght/lv2 (the lv2 syscall interface).

So now we have some headers defining functions like I described above, and then others where it follows sys_this_is_a_function style. I prefer to only use that when necessary, like when implementing standard POSIX headers. We also have some headers kinda thrown around without any real thought to their organization.

Comments?

@zeldin
Copy link

zeldin commented Jan 14, 2011

sys_blah_blah isn't POSIX, but using these names still do buy some portability versus other PS3/Cell SDK:s.

And I think any PRX call should use the official name (the one used to compute the function id number) when possible.

@ooPo
Copy link
Member

ooPo commented Jan 14, 2011

I agree, using the official name when possible should be encouraged.

@AerialX
Copy link
Member Author

AerialX commented Jan 14, 2011

zeldin: I know those aren't POSIX, I was referring to that nomenclature style as a whole.

As for using the original PRX names, that is a plus for portability... But goddamn Sony is even more inconsistent with those names >.>

@zeldin
Copy link

zeldin commented Jan 14, 2011

AerialX: I did not mean to imply that you thought differently, just to point out that the same reasons for conformity also apply there. Maybe I should have started the sentence with "Albeit" or something. Sorry about the confusion. ^_^;;

Yes, Sony do chose inconsistent names, but choosing the inconsistent names for compatibility and a common nomenclature in communication at least gives a reason for the inconsistency, granting it some legitimity. (Not meaning that it was legit of Sony to pick inconsistent names, but that it would be for PSL1GHT to pick the same names for compat reasons.)

@Parlane
Copy link
Member

Parlane commented Jan 15, 2011

I am not sure I'd be happy with "cell" in our function names if we were to use official prx lib func names...

@AerialX
Copy link
Member Author

AerialX commented Jan 15, 2011

Maybe someone should start a compatibility layer project, one that provides the same include paths as the sdk and #defines psl1ght names to the original prx names.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants