[vJASS] Dynamic Indexing Tutorial

[BPower]

I will step into the discussion before we are drifting too far away from the
thread purpose. I'm writing from a smartphone and will make a second, bigger post
later.

First of all this is a good tutorial, which guides beginners into the matter of coding
with vJass.

In the beginning I followed the discussion with huge interest, because latetly
I found my self using extends / delegate / basically vJass features not seen so
frequently in public resources. Pro/Contra discussions are very valuable, for me aswell as others who read this thread.
Now in the end you are nitpicking on not so important
things. It felt like comparing a Ferrari, Lamborghini and a Porsche
( we all want the Porsche, let's be honest the two other are just useless trophies )

Towards benchmarking: Yes useful when it comes to choosing between two type of
natives which do nearly the same ( SetUnitX vs SetUnitPosition, UnitAlive vs other alive checks)

Comparing SetUnitX to TriggerEval is mistaking apples for oranges.

I continue later from my pc.

Stay friendly guys.

 

[edo494]

I'm a fan of bloated college textbooks as much as the next guy, but sometimes it helps to have an overview of syntax and features before you learn about the inner workings of a language.

my last coin into the game, because as mentioned we are drifting away from this tutorial.

But he indeed fails in his(Mag's, not this one) tutorial to explain even basics of vJass OOP or inheritance syntactically, because he goes around the codegen all the time, and basically enforces the rule "you shall never use it, and if someone use it, laugh to their face so they learn to not use it", or we know the story of replacing monkeys with a ladder with banana right?

 

[Malhorne]

How can I stay happy and friendly when someone pops and say this tutorial shows "bad practice" and this is overall bad. And finish by pretending he has to write a style guide for vJASS. Do we have the next messiah?
If THW2 has to be like this, I'm out.

EDIT: I'm a bit mad today for different reasons sorry for this kind of post.
Just erase all of my posts if you find them offensive.

 

[BPower]

As long as nobody feels offended in person and we stick to the site rules,
there is no need to erase anything.

I like your tutorial. I'm not coding my spells in the style presented, but I like it.
Beginners can base their spells on your template and modify the code later, when being more used to vJass.
If I would know nothing about spell making in vJass
I would simply copy your final code and modify the fields to my needs.

What is ( fastest or ) best is very case specific and can hardly be measured by
anyone than the map-maker himself. Zwiebelchen makes a good point, when saying
that empty demo maps provide invalid test scenarios.
Their ( only ) main purpose is a visual presentation of the resource.
The need of maximum effeciency is also very code related.

Edit: I want to add that onDestroy has it purpose when it comes
to situations like struct B extends A. Here an instance of
struct B is stored as struct A.
In this case method .destroy() will
call A.destroy() and not B.destroy() which is obviously the incorrect destructor.
The trigger placed for onDestroy will evaluate the correct destructor.

 

[edo494]

just to clear things up, I never actually even talked about this tutorial per se I was always reffering to Mag's tutorial.

However, using simple inheritance without OOP(so you just make struct Spell which contains stuff like caster, target, pointX, pointY, rawcode) it shouldnt really be much more overhead. But yes, extending is like forbidden in Hive and Im not saying you should add it to the tutorial, since most people dont really do it anyways

 

[PurgeandFire]

But yes, extending is like forbidden in Hive and Im not saying you should add it to the tutorial, since most people dont really do it anyways

It isn't forbidden.

 

[edo494]

well, more correct would be, frown upon

 

[Malhorne]

Don't worry edo I understood you didn't talk about this tutorial.

 

[Zwiebelchen]

<Deleted>

Nevermind.