AlliedModders - New API and Syntax

AlliedModders (https://forums.alliedmods.net/index.php)

- Scripting (https://forums.alliedmods.net/forumdisplay.php?f=107)

- - New API and Syntax (https://forums.alliedmods.net/showthread.php?t=244092)

Re: New API and Syntax

Quote:

Originally Posted by Thrawn2 (Post 2169353)

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 for such an excellent test of the new syntax! I extracted a minimal test case from your file and now it's fixed on master.

Re: New API and Syntax

Quote:

Originally Posted by ddhoward (Post 2169679)

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

I don't think we could get away with breaking old scripts. What we can do though is build really awesome new tools, and only allow transitioned code in the new tools. I don't know if we'll get there, but if we do - we'll be shipping two compilers and two VMs in SourceMod.

Re: New API and Syntax

Thank you! i've been waiting for something like this for a long time.
Please, don't stop even if it means breaking compatibility with old scripts.

Re: New API and Syntax

Disliked this topic. For objects and classes we have C++

Re: New API and Syntax

But sometimes working with objects & classes is much easier...

Re: New API and Syntax

Nice, thanks for the fixes.

Found another bug regarding null passed as an any parameter though:

Code:

Foo(any foo) {}

public Bar() {

Foo(null);

}

Edit:
A rather cosmetic issue: combining getters and setters works if used like this
this.Processed = this.Processed + 1;
which is nice.
this.Processed++ garbles up the value though.

This is at least the case for methodmaps deriving from StringMap and setting an integer in the trie, i.e.

Code:

methodmap Foo < StringMap {

  property int Bar {

    public get() {

      int result;

      this.GetValue("foo.bar", result);

      return result;

    }

    public set(int value) {

      this.SetValue("foo.bar", value);

    }

  }

}

Re: New API and Syntax

Sorry, fat-fingered and garbled your post up a bit. re: increment bug, will take a look soon.

null not flowing into any is intended. any makes the bit-encoding of values observable which is illegal for object types, and null is considered an object type. While not strictly necessary in this case, it makes sure we don't have any GC-safety problems with null in the future.

Re: New API and Syntax

Quote:

Originally Posted by BAILOPAN (Post 2170562)

null not flowing into any is intended.

I see. It crashes the compiler though.

Re: New API and Syntax

Quote:

Originally Posted by Thrawn2 (Post 2170678)

I see. It crashes the compiler though.

Ah! Okay, that's fixed on master. The postinc/postdec bug is fixed as well. Turns out my initial implementation was just clownshoes. I made sure to test it better this time.

Re: New API and Syntax

So I read over this about 5 times. Maybe I'm stupid (I probably am) but I just don't see the need for this. The reason I got in coding 4 years ago, is because of the simplicity of the SourcePawn language and the need to make my server more unique. I remember not knowing what anything means (my worst enemy was tag mismatch), but still getting basic things done like printing to chat, setting health, etc. After awhile, I finally began to really learn why I was getting tag mismatch, why this was done, why that was done. With C#/Java or "C# Lite" as it's been called in the first post I still probably would have been unable to exactly understand why most things are done are that way. Sure I could probably make some basic edits (because words and I can read), but I wouldn't be able to get the true meaning of things as I did for SourcePawn. I think the current ease of language not only allows complete newbies to try, but it also opens doors. It certainly did for me.

Quote:

Originally Posted by BAILOPAN (Post 2167095)

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.

On the other hand, that (what I underlined) and the fact that I started with SourcePawn would probably explain why I am having a real hard time getting into newer modern languages, especially when they are object-based.