Discussion JassHelper -> some new features?

[Bribe]

1. Could Zinc have "readonly" like vJass? I know it's "nonstandard" but the method operators that must be used instead are hard to view when I'm trying to make a readable library.

2. Can modules be expanded on to force the containing struct to require some methods?

3. Can modules have overridable variables/methods? Using delegate variables is fine unless you have multiple structs delegating them for different purposes.

4. Please make a struct type similar to array structs that it disables the auto-generated allocation, but without the lame inability to extend/be extended.

5. [ljass]if (condition) { u = null ; }[/ljass] please make this stop causing syntax errors in Zinc. It's really hard to visually distinguish one-line "if" statements.

6. Please use the vJass "implement" keyword in Zinc instead of "module;" as the implementation looks really weird

7. Perhaps implement [ljass]default delegate structName[/ljass] so that boring people like me don't have to bang our heads against the wall to come up with some ridiculous name for it that we never use?

Thank you for (however unlikely) reading this.

 

[kingkingyyk3]

I think Vex should fix the bugs on vJass before adding these features, because Zinc will be compiled into vJass first.

 

[Lyerae]

I recall him saying that (aside from major (major) bugs) JassHelper wasn't going to be developed anymore.

 

[Bribe]

This game needs some added functionality, else it's going to die hard. The GUI users will switch to SC2 for simplicity, the JASS'ers will feel rejected.

 

[kingkingyyk3]

I recall him saying that (aside from major (major) bugs) JassHelper wasn't going to be developed anymore.
No, Vex said that he will continue it but no more new features will be added.

 

[Jesus4Lyf]

This game needs some added functionality, else it's going to die hard. The GUI users will switch to SC2 for simplicity, the JASS'ers will feel rejected.

Sorry, doomsday prophet. We've already had many of you tell us WC3 is dieing. No amount of hype about it dying is going to make it last any shorter than the original SC.

More amusingly, most of what you requested already works fine in vJass.

 

[Bribe]

2, 3, 4 and 7 are not supported in vJass, so technically "most" are not implemented. Technically.

 

[Jesus4Lyf]

2, 3, 4 and 7 are not supported in vJass, so technically "most" are not implemented. Technically.

>Can modules be expanded on to force the containing struct to require some methods?
Yes, just try to call the method from within the struct...

>Can modules have overridable variables/methods? Using delegate variables is fine unless you have multiple structs delegating them for different purposes.
Function interfaces answers for overridable methods, why the hell would you override variables..??

>Please make a struct type similar to array structs that it disables the auto-generated allocation, but without the lame inability to extend/be extended.
This is mildly unfortunate. When I require this, I swallow the fact that it will generate the allocator, which simply doesn't get used. Remember the good news: destroy is overridable. So is create. (Good job, Vex.)

>Perhaps implement default delegate structName so that boring people like me don't have to bang our heads against the wall to come up with some ridiculous name for it that we never use?
Lol? Rearrange to delegate structName default.

 

[Bribe]

>Yes, just try to call the method from within the struct...

Sorry, I meant the other way around. Force the struct implementing the module to create a method by a certain name.

>Function interfaces answers for overridable methods, why the hell would you override variables..??
Function interfaces? I'll look into that, thank you
Override variables the way I want is actually seemingly impossible as I wanted a static if inside of a module, but modules cannot implement static if's. So forget that part.

>This is mildly unfortunate.
Why compromise when you can fix the problem? The same thing goes with how I've had to use method operators in Zinc instead of readonly, though not as extreme because at least the operators inline.

>Lol? Rearrange to delegate structName default.
And the second delegate would be named, what, default2? What if I have 50 of them, that's just wrong. I suppose I could make yet another compromise. Might as well, because I'd rather take the heat than endlessly wait for someone who doesn't care to start caring.

 

[Jesus4Lyf]

>Yes, just try to call the method from within the struct...

Sorry, I meant the other way around. Force the struct implementing the module to create a method by a certain name.

Just try to call the method from within the module*.

I suppose I could make yet another compromise. Might as well

vJass is like that; just try to make it work without leaking...

 

[Bribe]

OK, I got readonly to work! You just have to create a module outsize of the zinc block with readonly members, and they behave exactly the same way as you'd expect. The rest of these suggestions have pretty much been solved by your guys' helpful replies, so this thread can be closed/ignored. Thank you for your help!

 

[Crazy_Dead]

What is readonly?

Sorry Offtopic.

 

[Bribe]

struct parent
    readonly unit dude
    method foo takes nothing returns nothing
        call KillUnit(this.dude) // valid.
        set this.dude = null // valid.
    endmethod
endstruct

struct child extends parent
    method foo takes nothing returns nothing
        call KillUnit(this.dude) // valid.
        set this.dude = null // syntax error: <dude> is readonly.
    endmethod
endstruct

Readonly means the variable can be set only by the struct in which it is declared. It gives the child-structs functionality with that variable, but it protects that variable from getting re-assigned.

 

[Crazy_Dead]

So like a private? Dont really get it... :S

Readonly makes this member to be unusable in other structs/functions, even by using [ljass]local data d = data.create()[/ljass] ??

 

[kingkingyyk3]

Readonly is read only.
You can get the value but not write it at outside of struct.
You can write/read it in struct only.
The feature is mainly for protecting the variable from being edited.

 

[Bribe]

Yea, but not merely out of struct context; even a struct that extends the struct with that variable will not be able to set that variable.

Private > No access outside of scope.
Readonly > Accessible but not assignable outside of scope. I think this only works for structs.
Public > Complete access outside and inside of scope.