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

Generally better includes #18

Open
Y-Less opened this issue Apr 2, 2019 · 1 comment
Open

Generally better includes #18

Y-Less opened this issue Apr 2, 2019 · 1 comment

Comments

@Y-Less
Copy link
Member

Y-Less commented Apr 2, 2019

Since most of these natives were written, the vast majority of the community has settled on a fairly consistent naming scheme, of the form Library_FunctionName. The default functions don't use this, but could do:

#pragma deprecated Use `PlayerText_Create`.
native PlayerText:CreatePlayerTextDraw(...);
native PlayerText:PlayerText_Create(...) = CreatePlayerTextDraw;

This works well with #15 and pawn-lang/compiler#234 (should that ever be done, though the macros in there can be used even now).

Since this is (IMHO) "better a_samp", it could be "b_samp" for compatibility.

@Southclaws
Copy link
Collaborator

I like this, more consistency would be good for this API.

I've also wondered about the file layout too - I'd imagine most people just include a_samp and transitively get the rest of the dependencies. The file names can sometimes seem arbitrary, for example a_samp contains a ton of miscellaneous stuff including player functions/events and vehicle functions/events, then a_players contains some player functions, no events, etc.

Another issue I've had with the libraries is how updates don't stack - this is partly Kye's fault for changing function signatures instead of just introducing new functions. Right now, the 0.3.7 code is fully documented with XML, which is useful for some, but the 0.3.DL does not have any of this. This also makes diffs between versions very difficult because of the documentation.

I'd like to have docs and branches for each version, and be able to merge and diff between but it's difficult to figure out a nice solution for this. One idea I had was to introduce files names after versions, a_samp_03DL for example which only includes the new APIs. This would make updates additive if there were a way to deprecate APIs without modifying their files... food for thought.

On top of this, I've wanted (and consistently forgotten) to change versions to use branches instead of tags - maybe just for 0.3.DL, see #7 - another reason for this is the const-correctness changes completely missed 0.3.DL and adding them requires manual work because the code is so different (thanks to documentation strings and API changes).

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

No branches or pull requests

2 participants