You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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`.
nativePlayerText:CreatePlayerTextDraw(...);
nativePlayerText: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.
The text was updated successfully, but these errors were encountered:
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).
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: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.
The text was updated successfully, but these errors were encountered: