Ok, as there is still some serious disagreement about the type system of JASS.
This is the reason why I will not use classes or structs. JASS already has a type system, and it uses the "type" keyword. This type system already has things like inheritance and implicit typecasting as well. It does not make sense to add a second type system. This would just muddle the language and make it messy. I have absolutely no intention of muddling it.
The primary challenge of using the JASS type is that it is a one liner. In order to use both standard JASS and xJASS together (JASS must be a subset of xJASS), then type somehow allow a block.
I now realize that splitting the scope up from the type is a bad idea. This changes the meaning of scope depending on whether a type with that same name was declared or not.
The expand keyword was introduced to state that we are expanding the type out into a scope. Scope doesn't make sense as a decorator unless it is applied to everything and can be used on its own, similarly to preprocessor. As function has a scope without the scope keyword, we can't do this.
One thing I kind of wanted to be able to do was nest types. However, if we don't nest types, then we can do something extremely smart with the compiler and allow for
JASS:
type a extends integer
endtype
If we encounter an endtype somewhere, then that was a block. If we don't or we encounter another type, then it was a simple type declaration. We can use operators to sort of nest types together, like we do in vJASS. As it doesn't seem like any other option is a good one, I'm of the opinion that types should not be able to be nested, thus we end up with just a simple type/endtype block.
We should also have this pretty cool thing
JASS:
type a extends integer
public function this.m takes nothing returns nothing
endfunction
endtype
scope d
public function m takes nothing returns nothing
endfunction
endscope
type b extends unit
// imports from a
public importer function this.a takes nothing returns a
return GetUnitUserData(this)
endfunction
// importer functions aren't included as traditional symbols
public function this.a takes nothing returns nothing
endfunction
// imports from d
public importer function d takes nothing returns nothing
endfunction
endtype
b bb = new b(...)
call bb.m() // cool? : D
call b.m()
This works similarly to delegates from vJASS except that it allows you to map to other types any way you like. Most importers will be optimized away or not used at all.
The only thing we'd seriously be missing from vJASS features is keyword, which we won't need with internal ^)^.
