[x6herbius]

It's been a long while since I've peeked into the world of SourceMod scripting and I'm keen to learn about the new methodmap syntax. I've been reading up on the wiki/forum but have a couple of questions, as I'm very used to C++ right now and might be getting some things confused.

1. Can methodmaps contain member variables? (From what I can see, I'm assuming they can't.)
2. How on earth do constructors work?? https://forums.alliedmods.net/showthread.php?t=260680 says that they have to either be empty or they have to return something using view_as, but I don't quite understand the implications of this. If I define a completely new methodmap that doesn't inherit from anything else, what should I be returning from the constructor?
3. I gather as per https://forums.alliedmods.net/showthread.php?t=269895 that user-defined destructors are no longer permitted. If I can't write a destructor, how do I clean up the things my methodmap has done when it is destroyed?
4. Additionally, that same page states that __nullable__ methodmaps can now no longer be compared to null. How do I then determine whether a methodmap passed to a function, say, is valid or null? Am I missing something?
5. When providing callbacks to other functions, can the callback be a function defined on a methodmap? If so, what's the syntax?

[WildCard65]

Originally Posted by x6herbius It's been a long while since I've peeked into the world of SourceMod scripting and I'm keen to learn about the new methodmap syntax. I've been reading up on the wiki/forum but have a couple of questions, as I'm very used to C++ right now and might be getting some things confused. Can methodmaps contain member variables? (From what I can see, I'm assuming they can't.) How on earth do constructors work?? https://forums.alliedmods.net/showthread.php?t=260680 says that they have to either be empty or they have to return something using view_as, but I don't quite understand the implications of this. If I define a completely new methodmap that doesn't inherit from anything else, what should I be returning from the constructor? I gather as per https://forums.alliedmods.net/showthread.php?t=269895 that user-defined destructors are no longer permitted. If I can't write a destructor, how do I clean up the things my methodmap has done when it is destroyed? Additionally, that same page states that __nullable__ methodmaps can now no longer be compared to null. How do I then determine whether a methodmap passed to a function, say, is valid or null? Am I missing something? When providing callbacks to other functions, can the callback be a function defined on a methodmap? If so, what's the syntax?

First off, methodmaps were designed to make using handles more OOP, in SP side of things, handles are represented with a 32-bit unsigned integer where internally in SM, the integer is an array index to an array located in sourcemod.logic.(so/dll) which holds a pointer to object handle is holding.

1. No, above text.
2. Constructors generally should return a cell view_as'd the method map (ex: view_as<MyMethodMap>(-1);
3. Unfortunately, the only workaround is to have a function you call to do the cleanup.
4. use something like: myVar != view_as<MyMethodMap>(<value representing invalid value<);
5. No unfortunately.

[friagram]

They are not structs or classes... They are wrappers to allow for semi transparent oop-looking calls.

Suppodedly this makes coding easier for people used to OOP, but then they think they can code in OOP in sp, which is not possible. There is a dynamic objects plugin to attempt to allow this type stuff, but that will just take you further down the rabbit hole.

[x6herbius]

Originally Posted by WildCard65 Constructors generally should return a cell view_as'd the method map (ex: view_as<MyMethodMap>(-1);

Does it matter what the number returned actually is? Ie. do I need to make sure that this is unique for each instantiation? Alternatively, if methodmaps are basically enhancements of handles, should I be making a habit of passing in a handle (or some type of integer) into constructors and just returning this?

A couple of other questions I've come across in the last half-hour or so:

1. With the advent of null, should I be using INVALID_HANDLE at all now?
2. I'm assuming it's possible to store references to callbacks in SP, given you can pass them around to functions, and to call these callbacks?
3. Linking 1 and 2, why am I not allowed to set a callback reference-holding variable to null? Eg:
   
   PHP Code:

   typedef MyCallback = function void(bool enabled);
MyCallback myCb = null; // To be set later 


[WildCard65]

Originally Posted by x6herbius Does it matter what the number returned actually is? Ie. do I need to make sure that this is unique for each instantiation? Alternatively, if methodmaps are basically enhancements of handles, should I be making a habit of passing in a handle (or some type of integer) into constructors and just returning this? A couple of other questions I've come across in the last half-hour or so: With the advent of null, should I be using INVALID_HANDLE at all now? I'm assuming it's possible to store references to callbacks in SP, given you can pass them around to functions, and to call these callbacks? Linking 1 and 2, why am I not allowed to set a callback reference-holding variable to null? Eg: PHP Code: typedef MyCallback = function void(bool enabled); MyCallback myCb = null; // To be set later

1. null == INVALID_HANDLE
2. I have no 100% answer, but my guess, probably no.
3. Function tag maps a cell to an array index within the binary's ".publics" section.

[Miu]

methodmaps are just alternative syntax for functions calls where the "object," a 32-bit cell, is passed to the method/property accessor as an implicit `this` argument. whatever `this` actually represents is up to you.

[Neuro Toxin]

You can use Dynamic to store properties using a class builder.

[friagram]

[fakuivan]

The only data (as seen from sp) that an instance of a methodmap is ``this``, or what you return on the constructor. ``this`` and the variable type are the only pieces of data that can help you figure out what "object" you are dealing with. An easy to understand example would be to create a methodmap called ``MyPlugin``that inherits its methods from, say a ``HashMap`` handle, then you can store data that can be retrieved by setters, getters or methods on the object represented by that handle. In C++ ``this`` terms it would be sort of equivalent to a pointer, that pointer points somewhere in memory much like ``this`` could point to anything, it depends on you to write code that knows what it represents.

[Neuro Toxin]

An example of a methodmap inheriting a hashmap.

https://github.com/ntoxin66/Dynamic/...maps/basic.inc