Static ifs no longer work ^_^

[Nestharus]

set delegate = base.create()

you get the idea : P... but the thing is with single inheritance you should just pass in the this parameter... you're going to be limited based on the base instances anyways, so return the base parent rather than your own. Also, with single inheritance, structs shouldn't use an allocation method as their allocation would be solely the base.

With multi inheritance, you need that, but not single... Vexorian doesn't even support multi inheritance, so wtf is he thinking.

 

[Vexorian]

Actually, I'm not just talking about the nested trigger evaluates, which I got over. I'm talking about the fact that a lot of it doesn't compile successfully, and that you can't inherit from multiple interfaces (or a struct-type and an interface).

Seriously, a lot of vJass features don't even compile correctly. Overriding the .destroy method on a subclass will not have the said .destroy method called when you destroy it as a higher class, for example (so what's the point of having inheritance if polymorphism doesn't work?). Another example is delegates don't seem compatible with inheritance, and private module members (another "inheritance" style feature) with the same name as another struct's member will stop you from accessing that struct's member. There's just lots of broken stuff. Sometimes if you have two levels of inheritance, and override destroy somewhere, you just can't seem to destroy it at a certain level...

I like vJass.

hehe, you know what the reality is? Nobody really cares or uses inheritance these features at all.

First of all, I always opposed to structs extending structs and nowadays I really feel like I should end their missery and just ban it. Back when you could only extend interfaces everything was so incredibly easy... And it worked great too!

Specially now that we have modules, there is no need at all for extends to work in structs.

anyway, somehow they managed to make me add them, and bugs happened. what's funny is that with every new struct feature, I consciously knew that a) The new feature would probably not work with 'inheritance'. b) I don't really depend on inheritance at all. c) Actually bothering to correctly implement it for inheritance would need me to take a lot more time instead of just releasing the new feature. d) The inheritance delphi code is awful and it gives me nightmares.

So, the decision has always and permanently been: Don't bother, wait till bug report.

And it really works, because the bug reports come years after that... the point is that nobody really uses inheritance... I am sure I could remove it. Modify xecollider and everything would be done except for a couple of libraries that can either be fixed as easily as xecollider or nobody uses.


So, I wonder if I should actually do it... I mean, the person that first forced me to add inheritance at all was a lunatic. The guys complaining about bugs with inheritance are also lunatics. I think life would be much easier without crazy features like that one.

 

[Vexorian]

On a more serious note. The vicious cycle with inheritance bugs is that too few people actually care enough about them to report them correctly instead of just doing work arounds. I for one am happy without having to touch them. If you guys (well, actually just Jesus, Nest is too annoying) want bugs with inheritance fixed. I can only think of one way. Starting right now. Give me code.

Report bugs in this way:
1. Source Code
2. What it should do
3. What it compiles to
4. Why it shouldn't compile to that

Of course, I can't fix issues that are by-design (and I am talking about the possible limitations related to storing the type in an array) due to backwards compatibility and that stuff. (Although I don't think it is really necessary to change this to have a) multiple inheritance and b) everything working correctly )

Since Jesus can't post in wc3c, do it here.

 

[Jesus4Lyf]

Edit: This was written before your above post. Reading now...

Spoiler

Dear Vex,

Thank you for visiting TheHelper.net before making such a decision. I can assure you that interfaces don't work either.

interface YouAlreadyKnowThis
    thistype doesntWork
endinterface

Jokes aside, this is a core system that I use for every spell I now create. I have encountered many, many bugs with inheritance while writing it, and having now written it, I don't touch it.

I fully agree with your comments regarding struct inheritance - I use it to remove code duplication. It would be shocking to implement those methods on every instance of a struct. How do you propose I do that without inheritance? And, whilst on wc3c.net this stuff may not be used, those systems are getting very popular here as ways to greatly speed up dev.

Interfaces are great for making it optional to implement methods, and inheritance is great for removing code duplication. I assure you that should inheritance be discontinued, I'll be happy to continue to use the latest JassHelper version which supports it. (Same goes for this abuse of crossing JASS code and external blocks (please don't fix).)

Sincerely,
Jesus4Lyf.

Edit:

Report bugs in this way:
1. Source Code
2. What it should do
3. What it compiles to
4. Why it shouldn't compile to that

I'll be happy to. Shall I start a new thread for that and PM a link, or something? Whatever works best for you, I'd just rather not take this specific thread off-topic.

 

[Vexorian]

Jokes aside, this is a core system that I use for every spell I now create. I have encountered many, many bugs with inheritance while writing it, and having now written it, I don't touch it.

No, really, everything related to interfaces worked great before I added extends to structs. Then I had to rewrite stuff and the bugs were added everywhere.

Inheritance (Even the official OOP one) is a terrible way to reuse code. Terrible. Lame and terrible. Implementation inheritance is like algae corroding some software projects out there. How to reuse code then? Well, to be honest even before modules there were so many ways to do it that I don't really get why I added structs extending structs in the first place ( We always had textmacros, functions and now we even have modules and delegates ...)

(Same goes for this abuse of crossing JASS code and external blocks (please don't fix).)

It was intended when EF and I were thinking of that feature.


BTW, I just fixed that funny static if bug. It was actually a bug with the ad hoc code to parse assignments and that's very old code so I think this probably affected other things as well.

Just post in this thread as the only post actually related with the comment static if bug is the first one.

. How do you propose I do that without inheritance? And, whilst on wc3c.net this stuff may not be used, those systems are getting very popular here as ways to greatly speed up dev

I highly doubt it but somehow I hate inheritance so much that if what you say is true I would really consider removing it.

private module members (another "inheritance" style feature) with the same name as another struct's member will stop you from accessing that struct's member

This is not going to change in the foreseeable future. just don't name private members the same way as other stuff. I require renaming private members to something else before structs phase to ... actually make private members work. It would get solved by having a good compiler that did everything in a single phase and was smart. But we don't have it yet. For now on just don't call your privates the same way as the stuff you are going to call... The same happens for libraries.

 

[Jesus4Lyf]

Alright. Here's #1.

1. Source code

struct Base
    method destroy takes nothing returns nothing
        call BJDebugMsg("Destroy Base #"+I2S(this))
        call this.deallocate()
    endmethod
endstruct
struct Struct extends Base
    method destroy takes nothing returns nothing
        call BJDebugMsg("Destroy Struct #"+I2S(this))
        call this.deallocate()
    endmethod
endstruct

struct Init extends array
    private static method onInit takes nothing returns nothing
        local Base s = Struct.create()
        call s.destroy()
    endmethod
endstruct

2. What it should do
Fire the Struct destroy method, which should then call the Base destroy method when .deallocate is called. (Instead, it just calls Base.destroy.)

3. What it compiles to (not really sure what you wanted here)
The problem is the s.destroy compiles directly to calling [LJASS]s__Base_destroy(s)[/LJASS].

globals
//JASSHelper struct globals:
constant integer si__Base=1
integer si__Base_F=0
integer si__Base_I=0
integer array si__Base_V
constant integer si__Struct=2
constant integer si__Init=3
integer array si__Base_type
trigger array st__Base_onDestroy
integer f__arg_this

endglobals


//Generated allocator of Base
function s__Base__allocate takes nothing returns integer
 local integer this=si__Base_F
    if (this!=0) then
        set si__Base_F=si__Base_V[this]
    else
        set si__Base_I=si__Base_I+1
        set this=si__Base_I
    endif
    if (this>8190) then
        call DisplayTimedTextToPlayer(GetLocalPlayer(),0,0,1000.,"Unable to allocate id for an object of type: Base")
        return 0
    endif

    set si__Base_type[this]=1
    set si__Base_V[this]=-1
 return this
endfunction

//Generated destructor of Base
function sc__Base_deallocate takes integer this returns nothing
    if this==null then
            call DisplayTimedTextToPlayer(GetLocalPlayer(),0,0,1000.,"Attempt to destroy a null struct of type: Base")
        return
    elseif (si__Base_V[this]!=-1) then
            call DisplayTimedTextToPlayer(GetLocalPlayer(),0,0,1000.,"Double free of type: Base")
        return
    endif
    set f__arg_this=this
    call TriggerEvaluate(st__Base_onDestroy[si__Base_type[this]])
    set si__Base_V[this]=si__Base_F
    set si__Base_F=this
endfunction

//Generated allocator of Struct
function s__Struct__allocate takes nothing returns integer
 local integer this=s__Base__allocate()
 local integer kthis
    if(this==0) then
        return 0
    endif
    set si__Base_type[this]=2
    set kthis=this

 return this
endfunction

    function s__Base_destroy takes integer this returns nothing
        call BJDebugMsg("Destroy Base #" + I2S(this))
        call sc__Base_deallocate(this)
    endfunction
    function s__Struct_destroy takes integer this returns nothing
        call BJDebugMsg("Destroy Struct #" + I2S(this))
        call s__Base_destroy(this)
    endfunction

    function s__Init_onInit takes nothing returns nothing
        local integer s= s__Struct__allocate()
        call s__Base_destroy(s)
    endfunction
	
function main takes nothing returns nothing

call ExecuteFunc("jasshelper__initstructs2691360")
endfunction

function config takes nothing returns nothing
    call SetMapName("Just another Warcraft III map")
    call SetMapDescription("Nondescript")
    call SetPlayers(1)
    call SetTeams(1)
    call SetGamePlacement(MAP_PLACEMENT_USE_MAP_SETTINGS)

    call DefineStartLocation(0, 0.0, 0.0)

    // Player setup
    call InitCustomPlayerSlots()
    call SetPlayerSlotAvailable(Player(0), MAP_CONTROL_USER)
    call InitGenericPlayerSlots()
endfunction




//Struct method generated initializers/callers:

function jasshelper__initstructs2691360 takes nothing returns nothing
    set st__Base_onDestroy[1]=null
    set st__Base_onDestroy[2]=null




    call ExecuteFunc("s__Init_onInit")
endfunction

4. Why it shouldn't compile to that
The line [LJASS]call s__Base_destroy(s)[/LJASS] should not directly call the destroy function, but instead do a lookup on which destroy function should be called, similar to other inheritance features such as interfaces. Another TriggerEvaluate thing.