[System] Dialog

[LeP]

Originally Posted by Magtheridon96

Just for the record, my map went down by 600KB when I stopped extending structs.

That pretty much falls under premature optimization.
If, and only if, these 600kB stop your map from working it's perfectly fine to optimize it.

[Magtheridon96]

Well, honestly, you made some pretty good points here.
But come on, who would need to extend a Dialog struct? :/

I know you're being imaginative and thinking of all these scenarios in which you can actually do something pretty cool with it, but.. well, I don't know what to say.

Maybe he can include a textmacro and use delegates so you can have the results obtained from extending without actually extending ^.^

[LeP]

Originally Posted by Magtheridon96

Well, honestly, you made some pretty good points here.
But come on, who would need to extend a Dialog struct? :/

I know you're being imaginative and thinking of all these scenarios in which you can actually do something pretty cool with it, but.. well, I don't know what to say.

Maybe he can include a textmacro and use delegates so you can have the results obtained from extending without actually extending ^.^

I already gave examples why you would extend this in particular.
But it's not only about a Dialog but about easy extendability in general.
Why restrict it without any good reason? And if you do, do it via extends array, so that i atleast get a compile-time error.

Textmacro + delegate is no real option.
Textmacros are for repetitive structures of code.
Delegates are cool, but too restricted in vJass. They are good for reusing but since they don't fulfill interface requirements you can't really use them in your polymorph code without giving up some of the good things you get from delegates. Modules work better in that regard under vJass (that is, reusing code which fulfills interface rules).

But both have there uses. They aren't exclusive.

[The_Witcher]

Come on guys :D
I will go back to the onDestroy method to keep the structure simple!
There won't be spammings of dialog destroys i think,
So this should be a solution everybody can live with^^

@Bribe: what does jass precendence mean? Sorry i am from germany^^
and i didn't change any configuration for jasshelper... I simply updated to cohadars mod...

[Bribe]

Precedence is when you can call function "foo" from above function "bar", but "bar" can't call "foo" because "bar" is below "foo".

Jass:

function foo...

function bar...

[overcold_ice]

onDestroy is a really bad thing to have in a struct @.@

[Adiktuz]

I was wondering why struct methods doesn't seem to follow precedence... I mean they still work no matter if the method was below or above and JH doesn't return an error...

[PurgeandFire]

Originally Posted by Adiktuz

I was wondering why struct methods doesn't seem to follow precedence... I mean they still work no matter if the method was below or above and JH doesn't return an error...

If it is below JH will usually either create an entire copy of the function(s) or it will create a trigger and evaluate it. (along with a few functions and variables) So precedence is still important if you care about the text compiled.

[Magtheridon96]

And the reason all of this matters:
It's not about the effects that one trigger evaluation will create, it's about the effects of all the trigger evaluations caused by the multitudes of systems in your maps.

[Adiktuz]

Oh, I see... :)

[The_Witcher]

To get rid of onDestroy things I updated the Dialog struct.
It extends array now and uses a simple recycler!

[Magtheridon96]

- The DialogButton should use a module initializer because in it's current state, the system will break if a DialogButton is managed by an external system using a module initializer :/

- The destroy method of the dialog struct should clean the DialogButtons properly. (Add a destroy method to your DialogButton struct)

[The_Witcher]

Originally Posted by Magtheridon96

- The DialogButton should use a module initializer because in it's current state, the system will break if a DialogButton is managed by an external system using a module initializer :/

- The destroy method of the dialog struct should clean the DialogButtons properly. (Add a destroy method to your DialogButton struct)

Updated. But the destroy method DOES clean the dialog buttons properly!

[Nestharus]

Yes, now it does, lol...

another thing, you forgot to call deallocate inside of your destroy method.