Jurst "Sized arrays are only supported as class members."

[Cokemonkey11]

The following is valid vJass:

library Shit
    globals
        private integer array s[12]
    endglobals
endlibrary

But in Jurst it is not. The problem can be side-stepped by enclosing every library's global block into a struct with static variables:

library Shit
    struct MyShit
        static integer array s[12]
    end
end

But clearly this is tedious and not valuable.

[peq]

I think the vJass code would be equivalent without the size, except for the fact that there is a .size member for the array. I think the array size is only relevant in vJass, when the size is > 8190. So is this ticket a request to have big arrays or what should be the purpose of this?

Btw: It is a bug that you can give the size for static array members. The behaviour should be the same as for global variables.

[Cokemonkey11]

I think I might not fully understand you.

It was my understanding that pre-defining array sizes in jass caused them to have upper limits, as in:

local integer array f[12] f[50] = 51

would break something. Am I wrong?

I am not asking for large arrays, just asking that jurst equivalent of valid vJass is equally valid.

I think that integer array f[12] is valuable in either case - it describes that the developer intends the array to be fixed size, which has implications on testing etc.

[Frotty]

Why do you make wild assumptions when you can test it faster than writing the comment? The vjass manual doesn't mention anything about checking the size on set/get, it simply allows for larger arrays and the use of a .size member. Also, vjass doesn't support local, sized arrays. At least the manual says so.

[Frotty]

http://www.wc3c.net/vexorian/jasshelpermanual.html#storarray

[Cokemonkey11]

@Frotty thanks for the response.

Why do you make wild assumptions when you can test it faster than writing the comment?

I tend to guess that I'm correct with overly high confidence - it's a personality flaw, I apologize.

I couldn't have tested it faster than this comment though (even compensating for both of your time) as I don't develop wc3 stuff on my primary work environment.

The vjass manual doesn't mention anything about checking the size on set/get, it simply allows for larger arrays and the use of a .size member.

My previous comment doesn't say anything about vJass - I actually thought sized arrays were a feature of plain jass. Actually, I'm still not convinced otherwise.

Also, vjass doesn't support local, sized arrays. \ At least the manual says so.

Can you show me where it says that? The link you provided seems a bit ambiguous. It doesn't seem like a flaw at all that local sized arrays are allowed.

As far as I can tell, sized arrays are perfectly valid in vjass.

[Frotty]

Seriously coke monkey, are you on coke? Normal Jass doesn't support any sizing. Why do you have to be convinced, you are just blabbering nonsense. How is my link ambiguous?? The first word in the paragraph is "GLOBAL". As far as I can tell, all you're saying is invalid, therefore I'm closing this ticket until you have done some research.

[Cokemonkey11]

You need to re-open this, or I will make a new issue. If you're not interested in supporting backwards compatibility with vJass in this instance, fair enough, but right now you're just being a hot head. (and an asshole)

The section you've sent me says "Sized Arrays", not "Global Sized Arrays". The sentence that follows is poor english and says:

Global arrays might sometimes require more index space, jasshelper introduces syntax for sized arrays, it serves two purposes: It will allow you to request more space, and it also allows you to place a .size field on global arrays.

From my understanding:

• The first clause introduces the problem (it would be unusual that local arrays require more index space)
• The second clause explains the solution (jasshelper supports sized arrays - nothing about global being a requirement)
• The final clause explains an additional supporting feature.

And, regardless of all this discussion about arrays in jass vs vjass, it's all irrelevant minutiae:

• vJass supports sized arrays in globals and locals (and I'm not even asking for locals!)
• Jurst does not.

[Frotty]

Nah bro. Provide working vjass codes with compiled code then we talk.

[Cokemonkey11]

@peq can you keep your dog on a leash?

[Cokemonkey11]

@frotty here you go:

Seamless sized arrays for big and small sizes - the vJass appears to the user as equivalent, but the compiler only generates getters and setters for the large ones:

http://peeeq.de/code.php?id=9043

And the generated code with getters and setters. Observe that accessing data in the else branch of the getters and setters actually accesses an index rather than throwing an error:

http://peeeq.de/code.php?id=9044

The output of such a program:

699
6999
69999
0

And note also that I was mistaken about local sized arrays. My recollection was being polluted by the valid, but unrelated code:

struct braap
    integer array sized[10]
endstruct

[Frotty]

Sorry that you have zero experience in ticket systems coke, it really shows your polluted and arrogant way of being. The ticket creator has to do something called specification. Look it up. I blocked you now and won't respond anymore, cya.

[peq]

It is not a goal of Jurst to be 100% vJass compatible. The aim is more like this:

If there is a feature which is both in vJass and in Wurst, then Jurst should support the vJass Syntax to make porting code easier.

I suggest you make a new ticket for a feature request of sized global arrays if you want this feature, and in there also suggest whether there should be bound checks and so on. Then we have a basis for discussion.

However, I don't see so many use cases for really big arrays, so I think it would be a low priority feature. You can give use cases in your new ticket, to convince me otherwise.

[Cokemonkey11]

@Frotty I'm sorry you feel that way.

@peq Okay, I've tried to provide more context this time. In my opinion, syntax errors as a result of extracting vJass to Jurst should be treated as bugs and handled on a case-by-case basis, but I think you're right that presenting this as a feature request is also valid.

[peq]

There is no such feature as "extracting vJass to Jurst", there is only a feature to extract custom scripts from a map file. It is completely independent from the used language.

[Cokemonkey11]

Aha! That explains the confusion. I guess I just got lucky that much of my code was valid Jurst.

So is "jurstifying" extracted code something we're actively against?

[peq]

Well, it would be a different feature and much more complicated. At least if you want it to work correctly. It would basically require to reimplement vJass with all its bugs and glitches in order to get a vJass->Jurst compiler.

Of course it would be possible to work with heuristics which work 90% correctly, but I think that would be more pain to use than the current porting process.

[Cokemonkey11]

Of course it would be possible to work with heuristics which work 90% correctly, but I think that would be more pain to use than the current porting process.

Well, rather than following heuristics, it would be nice to just support some mainline features.

The bugs/features I've been raising about Jurst are really only related to translating code.

I don't think anyone writes Jurst from scratch. This eclipse feature is really a great tool, and for me it's the main use for Jurst in general.