vitasdk / vita-headers

Documentation:
https://docs.vitasdk.org
MIT License
226 stars 91 forks source link

Discussion: Standards for entries in db.json #80

Closed devnoname120 closed 7 years ago

devnoname120 commented 8 years ago

Currently, some function names are prefixed with a '_' or two. The exact meaning of this prefixing is still debated.

Since they only convey information that is useless for homebrew developers, should we delete them all? From a homebrew developer point of view, adding an underscore to some functions but not to others is a annoyance.

In addition, the function names come from very different sources: it's currently inconsistent, and it would be very hard to fix the names to a chosen standard.

Do you agree with the suggestion of deleting all prefixed underscores from db.json?

@yifanlu, @173210, @xyzz, @DaveeFTW

173210 commented 8 years ago

There are some other symbols which have different prefixes such as vsh. We may make clear what prefixes are reserved by the SDK.

DaveeFTW commented 7 years ago

Ok I've given this some thought and think I'll write this to begin some discussion by laying out some ideas. Since we've already established headers and names for user types (so far), we should exclude them from these discussions and opt in for compatibility with existing homebrew. Kernel API is a blank canvas for us, we're still in beta(tm) and can change as much as we want. So I suggest for kernel:

For new contributions:

As such, all sce prefixes will be reserved by SDK.

d3m3vilurr commented 7 years ago

how about just use k prefix or suffix for the kernel function?(like kSceIoOpen or sceIoOpenK) ForKernel is too long suffix.

DaveeFTW commented 7 years ago

We could do two prefixes:

This would make it very clear that the developer is using the intended function.

DaveeFTW commented 7 years ago

For the record: adding a kernel prefix is not a technical limitation but a purposeful constraint to clearly convey to the developer which library they're attempting to use. Otherwise a misguided developer may link their kernel plugin against the user stubs.

yifanlu commented 7 years ago

My two cents: I have no problems with verbosity (especially in the age of auto-complete) if it makes the intention obvious. However one problem I run into with the ForKernel stuff is in modulemgr when I have functions called "sceKernelLoadModuleForPidForKernel" where "ForPid" denotes who I am loading for (in terms of context) and "ForKernel" denotes who is doing the loading. That's confusing and "ksceKernelLoadModuleForPid" seems cleaner.

yifanlu commented 7 years ago

in terms of the k prefix, is it recommended that developers exporting functions follow suit? For example should I change it to ktaiHookForImport?

DaveeFTW commented 7 years ago

I would advise developers to have the k prefix for consistency, but of course not required. You bring a good point about auto-complete: it would be very effective using k prefix for this also.

yifanlu commented 7 years ago

Another thing to consider is that some modules export for a ForDriver and ForKernel library with similar/same functionalities. Sometimes the NIDs are the same so it doesn't matter. But there might be (can't think of examples right now) functions whose NIDs are different but functionalities are the same.

DaveeFTW commented 7 years ago

I'm trying to not close your argument into a corner, but I think we'll need to find some sort of evidence to support that. In support/related, there are many kernel exports that are just wrappers for another export (be it ForKernel or ForDriver). How do we approach this?

frangarcj commented 7 years ago

I like the forkernel but maybe for auto completion is better to have a prefix I won't remove the sce And for the _ if there are no collisions I would remove it

yifanlu commented 7 years ago

Implemented in #99