[VoiDeD]

Originally Posted by WildCard65 I highly doubt that old scripts can compile on SM 1.7 atm... See: https://travis-ci.org/50DKP/FF2-Official But other then that, taking a look at method maps documentation link, they are REALLY AWESOME! Much neater then current system as it actually makes things easier to understand.

Try to reduce your problem to the simplest test case and file a bug.

[TheWho]

Again a milestone for every developer, nice!

[LambdaLambda]

Hate me, but I loved SP for it's syntax.

[BAILOPAN]

Originally Posted by LambdaLambda Hate me, but I loved SP for it's syntax.

I think you'll find the syntax much more fluid after using it for a bit. The lack of colons everywhere lowers code density. I do realize "new" had a very typeless feel to it that gets lost with "int". I think we'll be able to solve that eventually though.

[Thrawn2]

I've adapted the smjansson includes and test plugin to the new syntax to see how it feels. Here
This was quite easy and i'm really pleased with the new syntax. Good job!

Have one question though: How to deal with e.g. INVALID_HANDLE checks? Cast (i.e. tag) the methodmap as a Handle before comparison?

[splewis]

Looks awesome. Can't wait to give it a spin!

[BAILOPAN]

Originally Posted by Thrawn2 I've adapted the smjansson includes and test plugin to the new syntax to see how it feels. Here This was quite easy and i'm really pleased with the new syntax. Good job! Have one question though: How to deal with e.g. INVALID_HANDLE checks? Cast (i.e. tag) the methodmap as a Handle before comparison?

I forgot to mention it in the first post, but there's a new constant you can use, null, which is way easier to type. It should cast to any Handles or anything inheriting from Handle. INVALID_HANDLE should work too though if you still want to use it - if it doesn't, send me the code and I can take a look.

[Thrawn2]

Originally Posted by BAILOPAN I forgot to mention it in the first post, but there's a new constant you can use, null, which is way easier to type. It should cast to any Handles or anything inheriting from Handle. INVALID_HANDLE should work too though if you still want to use it - if it doesn't, send me the code and I can take a look.

Neat.

Using INVALID_HANDLE does work if I cast the methodmap to a Handle first, null on the other hand does only work if i cast it to the corresponding object type.

E.g. this does not work unless the comparison is: f != StringMap:null

#include <sourcemod>

public OnPluginStart() {
	StringMap f = StringMap();

	LogMessage("StringMap is not null? %d", f != null);
}

Without the cast it results in:
sm17.test.sp(6) : error 132: cannot coerce non-object type StringMap to object type null_t

Is there a way to avoid tagging of null or the other value altogether?

Also more questions if you don't mind:

• "any", while quite hacky was also quite useful. E.g. the old tests include used by smjansson had a method Tests_Is(any:a, any:b) which compared a to b. This worked with int, float, handle, i.e. you could throw anything at it. How would one specify an any: parameter in the new syntax?
• Will there be the possibility to define multiple constructors with a different set of parameters?
• When exactly is the destructor being called? When I delete the object and before the "old" CloseHandle is being performed?

And one bug report: it is possible to crash the compiler by using delete instead of CloseHandle.
It is easily reproducible by changing line 1013 of the previously linked smjansson include to use delete and trying to compile the test plugin that comes with it. Sorry for not having a smaller and more specific testcase for this.

Thanks!

Edit: The wiki says:

Currently only "get" accessors are available.

Is this accurate? The menus include is using property setters.

[BAILOPAN]

Originally Posted by Thrawn2 E.g. this does not work unless the comparison is: f != StringMap:null

Good catch! This has been fixed on master.

Originally Posted by Thrawn2 "any", while quite hacky was also quite useful. E.g. the old tests include used by smjansson had a method Tests_Is(any:a, any:b) which compared a to b. This worked with int, float, handle, i.e. you could throw anything at it. How would one specify an any: parameter in the new syntax?

The reason any is not available in the new syntax is fairly technical... the way it interacts with natives makes it impossible to do run-time type checking. It's verboten in the transitional syntax. On the other hand - it currently sees a lot of use and the replacements I have in mind (generics or top-type object) are nowhere near ready. I'll add any back on master for all but new-style natives.

Originally Posted by Thrawn2 Will there be the possibility to define multiple constructors with a different set of parameters?

Overloading - yes! Eventually, I hope.

Originally Posted by Thrawn2 When exactly is the destructor being called? When I delete the object and before the "old" CloseHandle is being performed?

delete is syntactic sugar for immediately invoking the destructor. That is, delete handle is equivalent to handle.~CloseHandle() (if that were valid syntax).

Originally Posted by Thrawn2 Edit: The wiki says: Is this accurate? The menus include is using property setters.

I've updated the wiki to reflect that setters are available.

[ddhoward]

All of the changes are opt-in, and old scripts will continue to compile.

Do you imagine this changing in the future? Once the 'transition' is complete, will these old scripts still function?