Hi, everyone! SourceMod 1.7 development is underway, and I'm excited to announce that SourcePawn is undergoing radical changes. The API is becoming object-oriented, and the syntax is becoming more C#/Java-like.
All of the changes are opt-in, and old scripts will continue to compile.
Without further ado...
Motivation
Pawn is derived from "Small C", which was made in 1984. It has a number of severe syntactic and semantic flaws compared to modern languages, and it's become quite painful to use. All of its problems can be ultimately blamed on the tag system. The tag system erases type information, which prevents us from implementing garbage collection, which prevents us from implementing better datastructures, true arrays, true strings, objects, and lambda functions.
Our ultimate goal is for Pawn to become a "C# Lite", but getting there is difficult: we have to rewrite the compiler, the JIT, and our entire API. That's an insane amount of work, so we're taking a new approach by introducing transitional syntax, transitional APIs, and a transitional type system.
Hopefully we're killing two birds with one stone: we'll make a major dent in the tag system, put foundations in place for our future API, and provide some major short-term improvements to Pawn usability.
Syntax Changes
As of SourcePawn 1.7, there is a new preferred way of declaring variables and function signatures. Fans of Java/C# will find it much more familiar. Here are some before and after examples:
PHP Code:
// Before:
stock bool:IsUserACrab(client);
// After:
stock bool IsUserACrab(int client);
// Before:
public OnReceivedString(const String:name[], Float:fval);
// After:
public void OnReceivedString(const char[] name, float fval);
// Before:
new Handle:PlayerHandles[MAXPLAYERS + 1];
// After:
Handle PlayerHandles[MAXPLAYERS + 1];
New-style declarations allow array dimensions to come either before or after the variable name. Empty dimensions should come before, and fixed-lengths should come after.
The new style is important for a few reasons. First, it visually removes the concept of tags. Second, it formalizes
int as an actual type, replacing "cells" (which were part of the tag system). Third, it formalizes
void, which will make it easier to implement modules in the future. Finally, it gives us a chance to replace old type names with better ones. For example,
String is not only misnamed, but will be confusing when we have a true
string type.
The new type names are
int,
float,
char,
void, and
object, and are only available in new-style declarations. They cannot be used as tags.
Methodmaps
SourcePawn 1.7 has a new feature called "methodmaps" for creating object-oriented APIs. Most users will not be creating their own methodmaps, so I defer to the
full documentation for the gory details. The idea is that you can now attach functions to tags.
For example:
PHP Code:
enum Player:
{
SERVER_PLAYER = 0,
}
methodmap Player
{
public void Kick(const char[] message) {
KickClent(this.Index, "%s", message);
}
property int Health {
public get() {
return GetClientHealth(this.Index);
}
}
property int Index {
public get() {
return int(this);
}
}
}
This methodmap lets us do things like:
PHP Code:
void CheckPlayerHealth(Player player)
{
if (player.Health < 5)
player.Kick("Wow, you are very bad at this game.");
}
Object-Oriented API
We've ported adt_trie, adt_array, and menus. For example, creating a simple menu beforehand might have looked something like this:
PHP Code:
new Handle:menu = CreateMenu(Menu_Handler)
AddMenuItem(menu, "de_dust", "Dust")
AddMenuItem(menu, "cs_assault", "Assault")
AddMenuItem(menu, "cs_thunder", "Thunder")
SetMenuExitButton(menu, true)
DisplayMenu(menu, client)
...
CloseHandle(menu);
Now, you can write it like this:
PHP Code:
Menu menu = Menu(MenuHandler)
menu.AddItem("de_dust", "Dust")
menu.AddItem("cs_assault", "Assault")
menu.AddItem("cs_thunder", "Thunder")
menu.ExitButton = true
menu.Display(client)
...
delete menu
Future Work
Most of our API has not yet been transitioned to methodmaps. I am hoping we'll be able to release 1.7 with a full object-oriented API, so if you want to use something in the includes that has not yet been ported, feel free to
submit a patch!
We may also consider an automatic porting tool for plugins once enough of the API is available.
The full documentation for the transitional syntax is here:
https://wiki.alliedmods.net/SourcePa...itional_Syntax
Please let me know if you have any questions.