A JASS Framework through vJASS - Discuss

03-25-2007, 10:26 PM

I was thinking the other day how practical would it be that, with the new additions to JASS by 3rd party tools, a framework (or however you would like to call it) for a semi-complete JASS object orientation was created.

The idea would be to build something on top of what already exist, and make it perhaps more safe, extended and user-friendly in many aspects. All handle-derived data types could have a class on top of it that would contain explicitely all its relevant functions as methods, as well as new stuff, like attaching objects to them in a clean-syntax way.

It could be something like

JASS:

 public CQuest myQuest = new CQuest()
 public CUnit myUnit = new CUnit('u000')
 public CPlayer myPlayer = new CPlayer(1)
 
 
  //setting attributes
 set myQuest.Name = "The Fall of Lordaeron"
 set myQuest.Type = bj_QUESTTYPE_REQ_DISCOVERED
 myUnit.Position(ThisMap.Width+64,ThisMap.Height+64) //since this could cause a crash, the method could validate agaisnt this, and put the unit in the closest safe location
 
 //dispose of the need for creating additional variables
 myQuest.Items.Add("Dispose of King Terenas")
 myQuest.Items.Add("Take the Crown")
 
 //Changing it on the fly
 set myQuest.Items[0] = myQuest.Items[0].Text + " with care (he's your father after all)"
 
 //extending functionality
 myQuest.AttachUnit("Executor", myUnit)
 
 
 myQuest.AddToPlayer(myPlayer)
 // - OR -
 myPlayer.AddQuest(myQuest)

I think the main highlights could be

- Faster development (perhaps)
- Improved readability
- Simplified maintenance

The big problem many people could find would be speed execution - since it is built on top of the current functionality, it would be somewhat slower, and it stressful maps, this could be significant.

What are your thoughts about this?

03-25-2007, 10:35 PM

Vexorian

No.

Because vJass is gonna have syntax to make wrappers.

So eventually

JASS:

    //syntax not decided yet
    wrapper unit
 
          property real x set SetUnitX(this,arg) get GetUnitX(this)
          property real y set SetUnitY(this) get GetUnitY(this)
          property real life set SetWidgetLife(this,arg) get GetWidgetLife(this)

          method kill takes nothing returns nothing calls KillUnit(this)
    endwrapper


//then

function stuff takes unit u returns nothing
    set u.x= u.x + 56.
    set u.u= 45.
    set u.life = 450.
    call u.kill()
endfunction


//becomes:


function stuff takes unit u returns nothing
    call SetUnitX(u, GetUnitY(x) + 56.)
    call SetUnitX(u, 45.)

    call SetWidgetLife(u)
    call KillUnit(u)
endfunction

then there is no performance hit

03-25-2007, 10:46 PM	#3
Alevice	So the intention is there already, good to hear. Any plans on doing a library? Also, does/will vJASS support inheritance? How would it work with it (ie, any extensions to widget would be inherently extended to its derivations as well?)

03-25-2007, 11:06 PM	#4
Vexorian	In one way or another it is not really necessary since we could just pase widget stuff. Writting the wrapper is not supposed to be something very frequent. But it might get inherited

03-25-2007, 11:13 PM	#5
SFilip	> The big problem many people could find By "many people" you mean the 10-15 using vJass ATM? Sadly not many know about it and even less understand the benefits. If something like this is ever to be made I'd wait until (hopefully) more people start using it. For now I don't think anything new is worth publishing, unless you intend to make it for personal use only. I do like the main idea though.

03-25-2007, 11:17 PM	#6
Vexorian	quantity of people using it means nothing to me.