[Dr. Greg House]

Originally Posted by friagram It's not really a big deal. Most of the time you can make a semi-transparent function to process the values into a container and remove/add nodes. Pretty well, I don't have any problems planning out things or how to do this stuff in my mind. Usually I can write 1500-3000 line program in a sitting and have it work just fine without any technical errors.

As said, its a point of relative sanity. There's no reason for me to choose the more or (even) most inconvenient solution. Doesn't matter how much code you can write in one sitting and "be fine with it", on a different topic I'd go so far and say this is post-hoc rationalization (which, it is).

In real life I can drive one of these while juggling with three balls, doesn't mean I should or will do it all the time where ever I go, even though I'm actually fine with it.
However, what this topic is not about, is teaching the art of decent coding. This is about whether or not sourcepawn would profit from certain features. And yes, enum structs have always been an intentional feature (as asherkin said here somewhere on one occasion) and they fill a void, exactly this void. They (or an actual struct replacement) have a reason to be there.

I would go so far to say that structs are more important in this particular environment than classes. Compared to other situations and environments you might encounter in software development, I think classes are the least useful here. I doesn't mean that they are useless, but again, it's a relative statement. On that note I'd like to know what dvander's stance on this actually is: How prominent are the following points to you:
-Classes (or in general a more "modern" design concept) should be part of sourcepawn to help developers from other branches to fit in more easily and make them feel more familiar
-Classes have an actual use in plugin-scripting situations

Ofc both point are valid and true, I'd just like to know out of curiosity which drives you more.

My personal stance during the almost 5 years I'm around:
It was weird at first. Coming from languages like c# and java (and actually not having very much experience in general five years ago) it felt odd to get used to the way of "thinking" in sourcepawn. But the way I approach and write plugins and mods has transitioned (I get it) over the years, especially the last 15 or so months. I rely very heavily on enum structs and inter-plugin-communication in sort of a master/slave relationship (again sourceirc is a great example to visualize the concept) now. But I don't only have the feeling that "it's just the way to go in sourcepawn", it feels generally right as well (besides the three compiler issues there are in regards to enum structs, the tag warning, the vector passing, and something else I actually don't remember because it's quite rare).

TLDR-section:
-(enum) structs are insanely useful
-Dvander what drives you more in regards to implementing modern-language kind of features (classes specifically); Usefulness in this particular environment or the challenge of modernizing your project and making people from different branches feel more welcome?

[BAILOPAN]

@ehha As I'm sure you discovered in the transitional syntax writeup, the goal is to make Pawn syntax more C/C#-like over time. Multiple languages in SM was a concept that died off very early in the project, like in 2005.

@Dr. House Mostly I want people to be able to look at SP without throwing up in their mouths. In the grand scheme of things I don't think it's that useful to very many people, so I'd say it's the challenge ;)

The problem with enum structs is pretty much that their semantics are a mess, and overlaid on top of a completely irrelevant construct. They entrain both enums and arrays with all sorts of grossness. The transition path will probably be something like: SM 1.8 introduces real structs, and warns about enum structs - SM 1.9 removes enum structs.

You'd still be able to use older compilers, of course.

[Mathias.]

I really love the idea of having 1.8 warning you about enum struct, hope it could guide us into changing our big messy enum struct codes into real structs. I really can't wait for them, thanks allot for your work guys.

[Mathias.]

http://gyazo.com/89f50806f14bc0d6d9c6eb045d4ef6b8
http://gyazo.com/ae35b9539d7800319de93c776c62a4b8

How we going to deal with this or how can we deal with this now?

NVM GetNativeFunction, just was not showing on the web API reference. But would function cast be there? From what I can see you will change it to pointers and as far as I know we won't have pointers in sourcepawn.

[VoiDeD]

Originally Posted by Black-Rabbit http://gyazo.com/89f50806f14bc0d6d9c6eb045d4ef6b8 http://gyazo.com/ae35b9539d7800319de93c776c62a4b8 How we going to deal with this or how can we deal with this now?

GetNativeFunction, but I imagine it might disappear someday.

[Mathias.]

Originally Posted by VoiDeD GetNativeFunction, but I imagine it might disappear someday.

if it disappear someday are we still going to be able to save functions somehow (to call private callbacks)

Also thanks allot for the quick answer

[BAILOPAN]

@Black-Rabbit: Yes. The problem is rather technical, but basically: a very common feature request we get is anonymous or nested functions. To do that the function type has to become something that cannot be casted to int (i.e., cannot have its tag stripped).

The real problem is that SourceMod's API basically assumes everything is an int/float. We need to introduce new, safe constructs in the API for holding more complex types. The new warning is basically a reminder that we need to do that, and that for people potentially using the type in broken ways, that they cannot rely on this in the future.

To summarize: yes, it will always be possible to communicate or store function values. What we need to kill off is stripping the tag.

[Mathias.]

@BAILOPAN: Thank allot for the info.

Is it okay if I ask help here if I get issue with some of the feature of the snapshots? No many people seem to used it yet and I am afraid that no one will answer me in the scripting section. If so here my first issue with datapacks

http://gyazo.com/1c9cb60a72dde6dc843a0c6af7aea841
http://gyazo.com/493f5a5638c13a9339031a66e9330213
http://gyazo.com/cae4d4498613dda0e4aea53484238a90

I'm trying to pass a datapack thru a RequestFrame but it dosnt seem like the Reset function actually reset the datapack and it is NOT a invalid handle.

EDIT: actually would it be possible to open a sub-forum for scripting section for the new syntax?

[Powerlord]

Originally Posted by BAILOPAN The real problem is that SourceMod's API basically assumes everything is an int/float.

That's not a surprise... it's based on Pawn, where everything (including Float and its fraternal twin Real) is a cell and a cell is a 32-bit integer.

Of course, now we're extending it to be more than Pawn...

[BAILOPAN]

Hi, all. I have made three more changes to the Transitional Syntax - I'm hoping these will be the last, because the first of them is rather significant.

The new keyword must now be used for invoking the constructors of nullable methodmaps - that includes any methodmap deriving from Handle. Thanks to VoiDeD for proposing this idea.

The second change is four new symbols have been keyworded: view_as, cast_to, var, and let.

The final change (which I'm not 100% sold on yet) is that a new operator has been introduced, view_as. It is a replacement for the tag operator that can use new-style types. The following old code:

PHP Code:

Float:array.Get(i) + 5.0; 


Can become:

PHP Code:

view_as<float>(GetArrayCell()) + 5.0; 


Note that this is not a cast. It is the same as retagging. It takes a value and pretends it is another type, without converting it or checking whether such a conversion would yield a valid value.

I realize this is rather verbose, but it's designed to indicate what's really going on, and it allows using type keywords that the unary operator does not. I'm hoping usage of this will be rather rare and that as we improve the API it will be less necessary. I'm also open to other syntax suggestions, although email/IRC/PM is preferable rather than this thread.

For those who have been bitten by the first change - here are the bash commands I ran to update our own plugins:

find . | grep "\.sp" | xargs sed -i 's/ = Menu/ = new Menu/g'
find . | grep "\.sp" | xargs sed -i 's/ = KeyValues/ = new KeyValues/g'
find . | grep "\.sp" | xargs sed -i 's/ = DataPack/ = new DataPack/g'
find . | grep "\.sp" | xargs sed -i 's/ = SMCParser/ = new SMCParser/g'
find . | grep "\.sp" | xargs sed -i 's/ = StringMap/ = new StringMap/g'
find . | grep "\.sp" | xargs sed -i 's/ = ArrayList/ = new ArrayList/g'
find . | grep "\.sp" | xargs sed -i 's/ = TopMenu/ = new TopMenu/g'