Raised This Month: $ Target: $400
 0% 

New API and Syntax


  
 
 
Thread Tools Display Modes
Prev Previous Post   Next Post Next
nergal
Veteran Member
Join Date: Apr 2012
Old 02-12-2017 , 17:34   Re: New API and Syntax
Reply With Quote #10

So I thought that I should give a little review about the new syntax for sourcemod and a general review of all the changes done.

I just want to say that before reading this review, please understand that this is just my opinion and I'm reviewing from my personal perspective.

So going on with the review.

My general opinion on the new syntax changes is very favorable, I like the fact that sourcepawn's types are actually brought out even though they're still just signed 32-bit ints underneath.

The code no longer looks similar to K&R C with the implicit ints everywhere whilst other types have to be explicitly declared.

I have really enjoyed working with the methodmaps, working with them made me wish they existed alot earlier in the past SourceMods but a good thing is a good thing.

Converting the standard SM library to use methodmaps also really helped in hammering in how useful they can be, so good on the SM Dev team to place some focus on updating the SM includes.

I've noticed plugins have become more stable and crash alot less compared to prior but I'm pretty sure this doesn't have much to do with sourcepawn as a language and the virtual machine it uses, but rather stability updates given to SourceMod.

going further down with methodmaps, the ability to add properties as small setter/getter functions really is more powerful than it looks and the fact that methodmaps have inheritance (compared to certain other languages) has helped alot with plugin-building.

combining a methodmap with the StringMap data structure effectively creates what I can consider to be classes.


Downsides...

Obviously, I should list the downsides as well.

I understand that one major feature that is planned for SourceMod is lambda functions and there's been MANY situations, too many to really count, where having lambdas would've shortened plugin development time and code lines. One such situation obviously is timers.

timers require one to make a timer-function which can clutter up code with a random function as opposed to inlining code as a lambda to the CreateTimer function.

It also makes me wonder if future SourceMod would support repeating timers on lambda functions as well. That would be a major godsend in my opinion.


One downside which would also help reduce plugin development if addressed is the restriction that methodmap methods cannot return arrays. 'tis a minor downside but useful in cases of entities and their velocity, angles, or vectors. Considering that sourcepawn is meant to power from games, the ability to work with vectors is a powerful one.

outside of methodmaps, a minor downside is the inability to declare + initialize a fixed-size array with a function that returns a fixed-size array. You must declare the array first THEN initialize it with the function call which was pretty much C behavior before C99 standard I believe.


Misc Ramblings

This one is more wishful thinking but I do wish that array indexes were overloadable like in C++. Purpose is so that the StringMap could actually be used like an array type by overloading the array indexing with strings instead of int expressions.

like
PHP Code:
StringMap map = new StringMap();
map["value1"] = 0.0

I know that priorly I was very vocal about the inclusion of a record/struct type but after much practical plugin development, I officially renounce my support about adding a record/struct type. I'm not against it but rather indifferent.

My reason why is because the StringMap data structure pretty much acts similar to a dynamic struct type, define a name and put a value to it. Not a specific value like a struct would require but any value you want.

In terms of plugins exporting natives to other plugins, I find that I can simply have a StringMap modified through natives to obtain or modify data between plugins.

One practical example of this is VSH2, VSH2 uses a player, boss, and gamemode methodmap.

The boss and player methodmaps share a client array of StringMaps while the gamemode methodmap is controlled by a single StringMap.

With such a system, I could recreate the Get/SetEntProp functions used to modify Source Engine game data.

PHP Code:
 //inside vsh2.sp at the near bottom of file
CreateNative("VSH2Player.GetProp"Native_VSH2_GetProp);
CreateNative("VSH2Player.SetProp"Native_VSH2_SetProp); 
PHP Code:
 // inside VSH2Player methodmap, under vsh2.inc
public native any GetProp(const char prop_name[64]);
public 
native void SetProp(const char prop_name[64], any value); 
Thanks to the SetProp method, plugin devs can inherit the natively exported methodmap and add new properties without having to define their own variables by setting a new string and initializing a value to it.

If I'm not mistaken, Toxin's Dynamic sp library also uses this same method.


This has been my 2 cents (more like a dollar) on the new api and syntax. Thank you SM Dev teams.
Sincerely, Nergal (pronounced 'ner' - 'gull')
__________________

Last edited by nergal; 02-12-2017 at 23:13.
nergal is offline
 



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -4. The time now is 21:25.


Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Theme made by Freecode