[Neuro Toxin]

Originally Posted by BAILOPAN Not yet, but it wouldn't be that hard I think. Want to file a bug? In the meantime, you can use static methods to return a constant.

https://bugs.alliedmods.net/show_bug.cgi?id=6567

[nergal]

btw, I'm still having trouble modifying menu handles...

[Neuro Toxin]

Originally Posted by Neuro Toxin https://bugs.alliedmods.net/show_bug.cgi?id=6567

I dont want to be pushy but is there any chance of this happening.

I want to build a static namespace for my VAC tracking API.

[nergal]

Originally Posted by Neuro Toxin I dont want to be pushy but is there any chance of this happening. I want to build a static namespace for my VAC tracking API.

why wouldn't there be any chance? Methodmaps are syntactic sugar.

static variables exist so there should be no reason why properties can't be static

but don't forget that property are just functions with a signature like

function property_type methodmapname_get_propname(methodmapname this);

If you want static properties, just make a static variable within the property scope and return that...

[Neuro Toxin]

Originally Posted by nergal why wouldn't there be any chance? Methodmaps are syntactic sugar. static variables exist so there should be no reason why properties can't be static but don't forget that property are just functions with a signature like function property_type methodmapname_get_propname(methodmapname this); If you want static properties, just make a static variable within the property scope and return that...

I agree.

The code below wont compile with a static tag on the property.

Originally Posted by Neuro Toxin Is it possible to do static properties in methodmaps? Eg: static int s_CollectionSize = 0; methodmap BaseCollection { public BaseCollection() { return view_as<BaseCollection>(0); } static property int Size { public get() { return s_CollectionSize; } public set(int value) { s_CollectionSize = value; } } } I wish to be able to do the below without having to make an methodmap instance. BaseCollection.Size = 666; PrintToServer("BaseCollection.Size=%d", BaseCollection.Size);

[Fyren]

Originally Posted by nergal btw, I'm still having trouble modifying menu handles...

Try reducing your code into a small test case/plugins you can post. You haven't really provided any useful information.

[nergal]

Originally Posted by Fyren Try reducing your code into a small test case/plugins you can post. You haven't really provided any useful information.

it's alright now, i simply had subplugins load to an array vector and then i list out the contents of each index and put it to the menu within the core plugin.

sucks you can't forward a menu handle but it's a very minor inability

[nergal]

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')

[Chdata]

blee bloo still no instance variables but keep u pthe good work

[nergal]

Originally Posted by Chdata blee bloo still no instance variables but keep u pthe good work

why do u need instance variables?