Converting spell from HandleVars to ABC

[Flare]

3) It's wrong when you give up code readability and cleaness for speed

Well, if I am the only one who is ever going to look at the code, and I can read it without any trouble, who gives a ****?

Doesn't help you if your constant is a common number.

Well, from your example, find and replace would have no trouble dealing with 0x100000 since every instance of it would have to be changed (and I doubt if that unlikely patch was released that Blizzard would make stupid exceptions)

When I get home, I'll grab you a whole bunch of BJ's that you should keep in your code as an exemple

Who ever mentioned BJ's in the thread (other than BJDebugMsg)??? And I know there are some BJ's that are relatively acceptable to use (I assume TriggerRegisterAnyUnitEventBJ is safe enough to use, and perhaps the PercentToInt)


Now, shall we stop arguing about the fine details (unless you want to continue via PM) since we are just cluttering the thread with somewhat irrelevant crap.

 

[Chindril]

You realize that inlined 0x100000 attachment is roughly 4 times faster than ABC? That isn't a "tiny" bit of speed bonus, that is a hell of a lot.

What ABC has to do with this ? I was talking about inlined -0x100000 VS a constant or function. I also asked "You're doing -0x100000 everytime you want to access the index of a unit ?" and you replied "Yes.", which implies that you are actually doing this is a map.

What if Blizzard released a patch tomorrow that changed the name of every single native. What would do you if you used those natives 834 times in your map without individual wrapper functions? What if Blizzard released a patch tomorrow that replaced Jass with a Warcraft-specific Lisp dialect? What if Blizzard released a patch that stole all your socks? Blah blah blah

I was just giving an exemple with the current situation, and I did point out it was unlikely to happen. But saying inlining constant like -0x100000 insides functions all over your map is a good coding practice is WRONG.

For the n time, 0x100000 is just an exemple...

- Chindril

 

[Gwypaas]

I want to see the day when Blizzard remakes their already working handle allocator lol

 

[TheDamien]

What ABC has to do with this ?

Since this is a thread about ABC (to some degree), I assumed you were comparing the -0x100000 method to ABC.

I was talking about inlined -0x100000 VS a constant or function. I also asked "You're doing -0x100000 everytime you want to access the index of a unit ?" and you replied "Yes.", which implies that you are actually doing this is a map.

Yes, I am. That doesn't mean that I type out set Foo[H2I(h)-0x100000] = X every time I want attachment to occur in my code, only that the H2I(h)-0x100000 operation is being done every time something is attached. The distinction is important.

I was just giving an exemple with the current situation, and I did point out it was unlikely to happen. But saying inlining constant like -0x100000 insides functions all over your map is good coding practice is WRONG.

I never said it was good practice. Notice that in my previous post I specifically implied that I do not do this. It would also be a waste of time as, between jasshelper and the map optimizer, the constants/functions will be inlined anyway.

If inlining them manually was the only option and provided a significant speed advantage, I would do it anyway. Even though it's "bad code practice", it would never end up affecting me to any significant degree.

 

[Grundy]

way to get off topic.

 

[Cohadar]

The sooner you all realize that speed at witch you make your map is much more important than the silly code speed optimization the better you will be.

Being an optimization freak never pays off in the long run.

 

[Chindril]

I so agree with Cohadar, and that's why I use ABC over other system. Yes it might be slower, but you don't have horrible text macros when you use it. Ease of use > all most of the time.

Before these system existed people used gamecache and were happy with it. Unless you do a map with tons of fast timers and/or physics and stuff like that, you don't NEED the extra speed.

And honestly, the way the programmer makes his trigger is far more important than the system he uses.

To Grundy: it was already offtopic, and I just wanted to bring up a discussion about optimization vs quality of code since the topic of system speed was bring up once again.

- Chindril

 

[TheDamien]

I so agree with Cohadar, and that's why I use ABC over other system. Yes it might be slower, but you don't have horrible text macros when you use it. Ease of use > all most of the time.

Sadly, the ease of use factor isn't that great when the system only allows you to attach to 3 handle types. So which presents more difficulty:

• Finding extra systems that support attachment to trackables, units and items?
• Typing a single line to invoke a textmacro?

Technically you "have" textmacros with ABC, the only difference is that the textmacro is already invoked (8 times more than it should be, too). It is honestly absurd to suggest that having to invoke a textmacro by yourself presents any difficulty whatsoever.

Before these system existed people used gamecache and were happy with it. Unless you do a map with tons of fast timers and/or physics and stuff like that, you don't NEED the extra speed.

And now people no longer use the GC, and hence are able to pack their maps with even better features. It's a phenomenon known as "progress".

And honestly, the way the programmer makes his trigger is far more important than the system he uses.

If that programmer is already finding it too difficult to type "//! runtextmacro", what state will his triggers be in?

 

[Chindril]

Stop lying, I never said it was hard to type TextMacro, I just find it horrible.
I don't mind if ABC does it as long as it stays in the library. I don't see it.

Set/Get TimerStructA and Trigger are pretty much the only functions I use. No reason at all to use a textmacro to generate properties. All it does is give fancy names to function, while in reality I only need a generic one.

If for some reason I would like to attach to other handles, I guess I could go write the functions in the ABC library, at least it stays out of sight.

- Chindril

 

[Flare]

... can the pair of you stop arguing over stuff within the thread? Continue the argument via PM if needs be, but the thread has gone way off-topic, so would be nice to get back to the topic at hand -.-

 

[TheDamien]

Stop lying, I never said it was hard to type TextMacro, I just find it horrible.

Oh, and here I was thinking you were actually serious with your "ease of use" doublespeak. I quote:

Ease of use > all most of the time.

So, what exactly were you talking about? If your only problem with invoking a textmacro is that it is "horrible", how does this relate to any sort of tangible ease of use advantage?

Set/Get TimerStructA and Trigger are pretty much the only functions I use. No reason at all to use a textmacro to generate properties. All it does is give fancy names to function, while in reality I only need a generic one.

There is nothing in the textmacro-based systems that prevent you from having a generic set of functions. ABC doesn't even give you a generic set of functions - by default the functions are specific to certain handle types..

 

[Cohadar]

Sadly, the ease of use factor isn't that great when the system only allows you to attach to 3 handle types. So which presents more difficulty:

• Finding extra systems that support attachment to trackables, units and items?
• Typing a single line to invoke a textmacro?

I already gave answer to that dilemma.
But for those not paying attention: look here.

 

[TheDamien]

It's only a "dilemma" if people are using ABC.

Every other attachment system allows attachment to the handle type - only the deranged ABC philosophy would force people to look for unnecessary and often redundant solutions to problems which shouldn't even be problems in the first place.

 

[Cohadar]

It always end's this way, some ignorant trying to presents his view about things he does not understand.

This went waaay off topic and in absolutely wrong direction, I recommend closing.

 

[TheDamien]

The way it "always ends" is with Cohadar stubbornly refusing to see reason. Feel free to fix your brain-damaged attachment system at any time - I'm just glad I'm using something better.

 

[Cohadar]

Ye I will consider that when you make any map worth playing. :thup:

 

[Flare]

can the pair of you continue the argument via PM or something? the thread went off-topic 20 posts ago ffs, i doubt it needs anymore crap added to it.