ZScript Discussion

[Major Cooke]

No, they won't. Constants go into the main block. They are not defaults they are class properties, not instance properties.

Corrected on the wiki. What about non-constants though?

[Graf Zahl]

Variable declarations go into the class scope Initialization has to be part of Default, because you may want to initialize them differently in subclasses. The way ZDoom initializes actors the constructor is a bad place for that. That part hasn't been defined yet, though.

[Major Cooke]

Understood. I take it they will be at some point, as user variables being replaced will make it hard to update to ZScript on first merge without the ability to define them.
By the way...

Code: Select all

class CFlameMissile : FastProjectile native

Where and when will we need the "native" keyword?

[Graf Zahl]

The 'native' keyword means that this class contains a native definition in the engine and tells the compiler to connect the script class with the internal one, just like it does in DECORATE. You won't be able to use this in user side code at all.

[Xaser]

To echo Gez's sentiment from the previous thread, I'd like to see the "Default" block be renamed to something like "Properties". I get that it means "default values to set on a new instance of this class", but that definition's going to escape users not familiar with the internals. At first glance it looks like the "wrong" word to use in such a context.

[EDIT] For the sake of contributing something that's not a syntax nitpick: the thing I'm most keen to see is non-anonymous functions of some sort (i.e. custom action functions). Being able to call something like A_FirePsychicPower(...) and move all the stuff that goes into that into a sane function def, that'd make a world of difference.

[ZzZombo]

So I guess it's possible to have an array of references to actors, but not other kinds of containers like dictionaries and whatnot, you know, more advanced ones?

[Major Cooke]

@Xaser: http://forum.zdoom.org/viewtopic.php?f=4&t=53797

Eventually. Probably won't happen on the first merge though.

[Graf Zahl]

[EDIT] For the sake of contributing something that's not a syntax nitpick: the thing I'm most keen to see is non-anonymous functions of some sort (i.e. custom action functions). Being able to call something like A_FirePsychicPower(...) and move all the stuff that goes into that into a sane function def, that'd make a world of difference.

Let's go at it step by step. The grammar supports such functions but right now the code generator does not. My first priority is to make the stuff that DECORATE already supports work - because after that I can start cleaning up and restructuring the code generator. And before that isn't done it makes little sense to implement more features.

[Graf Zahl]

So I guess it's possible to have an array of references to actors, but not other kinds of containers like dictionaries and whatnot, you know, more advanced ones?

Again: What's the point of going after step 20 first, when the implementation right now is only at step 5? The groundwork in the grammar is there, but this all needs to be implemented, and that's not a simple task to get working.

[Graf Zahl]

Here's something I want to get a public opinion first, because unlike the const syntax I believe this is really going to confuse users.
I can't help but notice that the grammar has taken some really bad influence from Lua and this looks like another such example:

If you want to declare initialized local variables it has to be done like this currently:

Code: Select all

			int localint, localotherint, i, j = 0,1,2,3;

instead of what pretty much everybody would expect:

Code: Select all

			int localint = 0, localotherint = 1, i = 2, j = 3;

It's only because I already knew about the Lua stuff that I could guess where this was going when the second approach did not work, but if I as a programmer cannot see the sense in here, what about the future user of this tool?

Edit: It gets worse. This passes the parser but the result is bogus:

Code: Select all

			double localfloat = 1.234, localfloatnotinit;

No, it doesn't declare two variables, it only declares one, 'localfloatnotinit' is considered an initializer for a non-existent second variable. I guess I don't wait for opinion, this is a disaster just waiting to happen with the given syntax.

[juizzysquirt]

First example feels really, really awkward. I get the idea of "efficiency" there but just imagining reading several lines with 5 or more variables (of someone else's code) makes my head hurt.

[Nash]

I got cross-eyed reading that. That looks confusing as hell. I hope you can change it to the usual, expected syntax. I'm already used to writing like this for many years:

Code: Select all

int dx = 1,
    dy = 2,
    dz = 3;

[Major Cooke]

Edit: It gets worse. This passes the parser but the result is bogus:

Code: Select all

			double localfloat = 1.234, localfloatnotinit;

No, it doesn't declare two variables, it only declares one, 'localfloatnotinit' is considered an initializer for a non-existent second variable. I guess I don't wait for opinion, this is a disaster just waiting to happen with the given syntax.

So we basically need to go with:

Code: Select all

int num1 = 1;
int num2 = 2;

and your above example is a no-go?

I don't mind that one bit honestly. Since this is how user vars had to be treated, I'm used to it -- with the added bonus of zscript's capable of being assigned immediately instead of relying on the states to do it.

[Gez]

Here's something I want to get a public opinion first, because unlike the const syntax I believe this is really going to confuse users.
I can't help but notice that the grammar has taken some really bad influence from Lua and this looks like another such example:

If you want to declare initialized local variables it has to be done like this currently:

Code: Select all

			int localint, localotherint, i, j = 0,1,2,3;

Indeed I don't like it. Not that declaring a lot of variable in the same line is good practice anyway, but separating the variables from their initial value seems like a good way of getting both lists out of syncs if variables get added or removed.

E.g. suppose someone tries to refactor the code to see if localotherint is really needed, and so comments it out for a test...

Code: Select all

			int localint, /*localotherint,*/ i, j = 0,1,2,3;

Yeesh! With the C-style syntax there's no risk of that happening.

[Graf Zahl]

Thanks. That list of reactions pretty much sums up my own. Of course I am changing it.