Jurst doesn't support vJass "property-style" operator getters

[Cokemonkey11]

The following is valid vJass:

        method operator title takes nothing returns string
            return .titleText
        endmethod

Which allows you to do something like let f = Struct.title. This throws a syntax error in Jurst.

[Crigges]

Noes? Jurst's goal isn't it to support all the vJass features. It should just help to convert vJass stuff to a more wurst like style. I don't think peq wants to implement such features.

[peq]

What Crigges said is right, but there is a plan to add custom getter and setter methods to Wurst and Jurst. The official syntax would be more like

function getTitle()
    return this.titleText

So just creating a normal function with a certain naming convention.

I might add the strange vJass syntax to Jurst to make porting code easier.

[Cokemonkey11]

The operator syntax is much nicer than specifying a special naming convention.

Maybe consider the @property style used in python? I quite like that - https://en.wikibooks.org/wiki/Python_Programming/Decorators

Edit: And it would definitely be nice if the vJass translation just worked with Jurst...

[Frotty]

Vjass operator syntax has always amazed me with it's uselessness. So it's definitely needed in Jurst. Using only . And not this. Or nothing should be allowed too, since it is a very often used feature and we want shit code. So go on peq

[peq]

I think the shortform with .bla is already supported in Jurst. I have no problem with making Jurst ugly if it makes it more compatible with vJass and if the change is purely syntactically (i.e. it can be translated to Wurst without any name analysis, type checking or other advanced transformations).

[Cokemonkey11]

I think the shortform with .bla is already supported in Jurst.

Hmm, if that is already supported, perhaps what we really need is an update so that Eclipse "extract to files" (from vjass) knows how to deal with the vjass syntax to transform it into the valid jurst equivalent. Am I correct?

I'm happy for Jurst to be ugly, too :) I see it as a stepping stone to real Wurst.

[Cokemonkey11]

@peq what was the result of this discussion?

[jlfarris91]

I stopped in to ask for proper property support in wurst and found this thread, so I'll add my 2 cents here. I come from a heavy .Net background and I'm fond of the syntactic sugar that properties provide; I'm not a fan of writing 'get' 'set' everywhere, especially when it is obviously implied by the context the property is used in. I can understand the "official syntax" argument, however, if it is indeed the official syntax then I would expect it be applied to everything official. There are many places in the standard library that do not follow the get/set property syntax and muddies the API; for instance, in Unit.wurst where you can see the inconsistencies between these 2 properties:

public function unit.suspendXp(boolean suspend)
	SuspendHeroXP(this, suspend)

public function unit.isSuspendedXp() returns boolean
	return IsSuspendedXP(this)

public function unit.getLevel() returns int
	return this.isType(UNIT_TYPE_HERO) ? GetHeroLevel(this) : GetUnitLevel(this)

public function unit.setLevel(int level, boolean showEyeCandy)
	SetHeroLevel(this, level, showEyeCandy)

Disregarding the mismatched names of suspendedXp and isSuspendedXp, I'd prefer the syntax of myunit.isSuspendedXp = bla as it reads cleaner. And, this may be nitpicky but, in regards to functions that return bools; it is best that they are named in such a way that they answer a question and for boolean properties "getIsSuspendedXp" doesn't read as well as the trimmed "isSuspendedXp".

Either way, just a suggestion. Thanks!

I'll also add that I am loving Wurst - you guys are doing an amazing job. Thanks for your hard work!

Edit:

there is a plan to add custom getter and setter methods to Wurst

Whoops, missed this in the first read-through - are we talking about the same thing then?

[Frotty]

Jurst is deprecated