ZScript Discussion

[ZzZombo]

Excuse me, but... what?

"The flags are one of the most annoying and most error-prone things in the C++ code because of the required application of boolean logic. With single variables you just set them to true or false - removing a huge cause for progamming errors."

How having 'target.flags.shootable=false' is any different to 'target.bShootable=false'?

[Graf Zahl]

I thought you wanted them back as FLAGS?

As for that added piece of verbosity: Why? It doesn't offer any clarity, it only forces people to type more.
pos and vec, on the other hand are vectors, they can be used as a single entity, and their single components can be accessed, but there's no reason to access the flags as a complete entity. AFAIK there's one or two places where the flag set is restored in its entirety and that has already been offloaded to an internal function to avoid the problem of missing a newly added flag word because that has already happened in the past.

[MaxED]

Why is "A_JumpIfTargetOutsideMeleeRange" named the way it's named? It doesn't offer any clarity, it only forces people to type more. It should've been named "ajitomr" instead!

[ZZYZX]

What would you suggest? Any OOP language I know allows calling static methods with an object as qualifier on the left side, but since no self pointer is passed, it's just the same as calling them with a class name on the left.

This particular part is a design flaw in any OOP language. Not sure why is this design flaw that popular.
Trying to access static members from instance should cause compile-time error because it doesn't make sense and causes confusion.

As for that added piece of verbosity: Why? It doesn't offer any clarity, it only forces people to type more.
pos and vec, on the other hand are vectors, they can be used as a single entity, and their single components can be accessed, but there's no reason to access the flags as a complete entity. AFAIK there's one or two places where the flag set is restored in its entirety and that has already been offloaded to an internal function to avoid the problem of missing a newly added flag word because that has already happened in the past.

Sounds better. Looks better. Doesn't look like 1000 fields stuffed into one poor class. Also, flag fields are not actual fields, but interface to uint flags. These should be a separate generalized class type that provides an interface to define string constants for one or multiple uint variables.

[ZzZombo]

I don't like the 'b' prefix, plain and simple as that, as well as others from the same notation, as in 'iCount', 'sName' or 'mHealth', because they are overly verbose in strongly typed languages. In loosely typed they do have their merits, however. And ZScript IS strongly typed, so why was it even used in the first place; you yourself just said "'flags' don't bring any clarity", how does 'b' in flag names do it then? It doesn't as well. Couldn't we use no prefix for flag names? Or use 'f' for it, as it least it would distinguish the flags from some generic boolean variables, so that in fact would actually clarify their meaning.

EDIT: people responded while I was typing, so I shrank my post in order not to repeat them. And despite offering the 'f' prefix, I'm still in favor of 'flags' being used.

[ZzZombo]

"What would you suggest?"

The static keyword? Even if you discard it and don't change anything in the VM, it could be a useful tag for users and editing software. And while I don't really agree with ZZYZX with making this an error, a warning would be great, I think.

[Graf Zahl]

I don't like the 'b' prefix, plain and simple as that

Let's not start about naming conventions. ZDoom has been very inconsistent here since all eternity. It's impossible to clean this up without creating inconsistencies between native and scripted code.

About the b prefix for the flags, that's because of avoiding naming conflicts with these auto-synthesized fields, as I said before.

Why is "A_JumpIfTargetOutsideMeleeRange" named the way it's named? It doesn't offer any clarity, it only forces people to type more. It should've been named "ajitomr" instead!

Because that name tells a story. What story does it tell, if one member is part of a subfield named flags or not? It's the ACTOR that's shootable, not the flags belonging to the actor. The 'flags' has no semantic meaning aside from telling that this is not a normal variable. But the nice thing is: The VM's instruction set ALLOWS me to treat the flag as a normal variable and I like that!

Sorry, but in this case I have made up my mind and won't change it. This is nitpicking in the wrong spot. bShootable could just as well be turned into a genuine native boolean if I wanted to. What then?

[MaxED]

ZDoom has been very inconsistent here since all eternity, so nothing stops us from throwing even MOAR inconsistencies into the mix!

That's kinda sums ZDoom development approach, doesn't it?

The VM's instruction set ALLOWS me to treat the flag as a normal variable and I like that!

This gives me strong PHP vibes, as in tailoring a scripting language in a way, which makes it easier for it to be processed by the parser, not for a user to write code.

[Gez]

I don't think any sort of prefix that is also a valid character for a name is a reliable way to separate. IMO "shootable" is the name of the flag and it should remain intact as a word. Adding a prefix like flags. has the advantage that it's unambiguously separate from the name. You could have a flag named "bshootable" which would then have to be referenced to as bbshootable in ZScript. Having a prefix that ends in a character invalid for a name is the only reliable, safe, robust way you could make this work. So flags.shootable (or f.shootable, or b.shootable, or if you don't like the dot it could be whatever else that isn't a letter, number, or underscore) gives you a 100% guaranteed unambiguous certainty that "flags." (or whatever) isn't part of the property name.

Basically I don't see actor.bshootable to be more sure than actor.shootable. You're making collisions a little bit less likely, but you're not making them impossible.

[Player701]

A weapon state only needs a specifier if it's supposed to be used on the weapon's item states to restrict the self pointer.

Sorry, I didn't understand. I'm a bit confused by all this. Maybe you can give an example where "States(Weapon)" is mandatory another one where it is not? Thanks in advance.

[Graf Zahl]

The VM's instruction set ALLOWS me to treat the flag as a normal variable and I like that!

This gives me strong PHP vibes, as in tailoring a scripting language in a way, which makes it easier for it to be processed by the parser, not for a user to write code.

Ok, in what way is it easier to write code if users had to write "if (target.flags.bShootable)" or even "if (target.flags & MF_SHOOTABLE)" instead of "if (target.bShootable)". Of these 3 variants the last one is by far the most concise because it leaves no question about WHAT is shootable - it's the target! It's not the flags!

[Graf Zahl]

A weapon state only needs a specifier if it's supposed to be used on the weapon's item states to restrict the self pointer.

Sorry, I didn't understand. I'm a bit confused by all this. Maybe you can give an example where "States(Weapon)" is mandatory another one where it is not? Thanks in advance.

States(Weapon) as such is never necessary. But States(Actor) is necessary if you want to do stuff in the item states of a weapon. However, since the defaults can be overridden by an actor property it is possible to define subclasses where the default does not include 'Weapon', for whatever reason. Maybe someone wants to have better error checking capabilities?

[Player701]

States(Weapon) as such is never necessary. But States(Actor) is necessary if you want to do stuff in the item states of a weapon. However, since the defaults can be overridden by an actor property it is possible to define subclasses where the default does not include 'Weapon', for whatever reason. Maybe someone wants to have better error checking capabilities?

I seem to be getting it now... thanks.

However, since the defaults can be overridden by an actor property it is possible to define subclasses where the default does not include 'Weapon', for whatever reason.

You mean DefaultStateUsage?

[Graf Zahl]

Yup. I saw no point hardcoding it so I made it an actor property.

[MaxED]

Of these 3 variants the last one is by far the most concise because it leaves no question about WHAT is shootable - it's the target! It's not the flags!

Code: Select all

// OHMYGAWD! WHAT ARE WE CHANGING HERE??!! IS IT TARGET? OR POSITION? WE JUST DON'T KNOW!!!
target.pos.x += 1;