[vJass] onDestroy & deallocate()

[Bribe]

Just a question, since sometimes I see this.deallocate()in the onDestroy method, sometimes I don't: does the onDestroy method need to call the generated destructor?

In the JassHelper manual, I read that the onDestroy method needs to call .deallocate(), but then directly after that they give an example script of an onDestroy method that does not use .deallocate().

I would imagine omitting something like the native destructor would be detrimental to the stability of the struct?

 

[Anachron]

AFAIK deallocate() runs the same method destroy() and is only a synonym for it.
Or maybe it's like "create" and "allocate", while allocate() is the core creation and create the advanced parameter function, so that destroy is the core and deallocate() can have parameters.

 

[PurgeandFire]

I think a manual this.destroy() should be enough. The onDestroy method is fired, well "on the destroyal". As Anachron said, .deallocate() is the same as .destroy(), but .deallocate() doesn't fire the onDestroy method. I don't think it is necessary to deallocate() in the onDestroy method though, unless you want to control at what point it is destroyed or something weird like that. Especially since so far, I haven't had any problems using merely .destroy().

It is essentially the same reason we use .allocate() in static method create methods.

EDIT: Perhaps you misinterpreted this line?

Since 0.9.Z.1 you may also override the destroy method by declaring your own one. Then use deallocate to call the normal destroy method.

By "calling deallocate to call the normal destroy method", it means that deallocate will do the normal destroying of the struct without calling the onDestroy method. I guess it is a bit confusing since they use the word "method" when they should use something like "process". =)

 

[PurplePoot]

No it doesn't. It means that you can write your own destroy() function similar to how you can write your own create() function; when you do, you have to free the memory manually with deallocate() similarly to how you would have to get it with allocate().

 

[Anachron]

No it doesn't. It means that you can write your own destroy() function similar to how you can write your own create() function; when you do, you have to free the memory manually with deallocate() similarly to how you would have to get it with allocate().

What is the idea to be able to write the own onDestroy and destroy method? Shouldn't one be enough?

 

[PurplePoot]

onDestroy predates destroy() being overrideable. Perhaps somebody can think of a situation in which you should have an onDestroy, but I think it's probably in there for backwards compatibility now.

 

[Anachron]

I always use onDestroy, since it's called when using .destroy().
I don't see a reason when I should use deallocate().
(Since it doesn't call onDestroy where you clean up the leaks)

 

[PurplePoot]

I have had reasons in which I have had to add faux-destroy methods (before this feature) because you couldn't override destroy.

Here's an example taken from some random map code:

    method free takes nothing returns nothing
        set this.units = this.units - 1
        if this.units == 0 and this.maxunits > 10 then
            if this==trig then
                set trig = 0
            endif
            call DestroyTrigger(this.source)
            call this.destroy()
        endif
    endmethod

 

[PurgeandFire]

EDIT: Ohh... I get it. My bad. I thought .deallocate() wouldn't call the onDestroy method, but it does. That explains the crash, it caused an infinite loop.

 

[Anachron]

Okay great, so it's like a conditional destroying.
Anyway, I would just make the method destroy private and make another method called terminate() which will run destroy when conditions become true.