View Single Post
Old 10-24-2009, 02:51 AM   #20
grim001
requires vJass
 
grim001's Avatar


Code Moderator
 
Join Date: Nov 2006
Posts: 1,540

Submissions (10)

grim001 is just really nice (277)grim001 is just really nice (277)

Send a message via AIM to grim001
Default

Quote:
Originally Posted by Anitarf
That's one compromise I had to make in order to ensure that players get bounty correctly whenever the damage is supposed to kill a unit.
Would it be possible to only do this when you know the damage will be fatal?

Quote:
Originally Posted by Anitarf
The problem is that it's DamageEvent that requires DamageModifiers, not the other way around.
However, you can change the design a bit to get around this by calling RunDamageModifiers from within DamageModifiers using a function registered with any damage detection system. The only problem would be that the final modified damage value wouldn't be passed through to other events, however how can correct that for IDDS by using the SetDamage function it includes. LLDD relies on the native event responses, but you could make a function that returns the modified damage value.

Quote:
Originally Posted by Anitarf
I think the first statement is a poor argument; it is after all also the truth that many people will avoid this system because it's in vJass and not GUI.
It's not an argument; it annoys me that people fear extends. But making it understandable for a wider audience can only be considered an upside. I found the function interface example from my last post to be pretty elegant, too.

Quote:
Originally Posted by Anitarf
I can see the problem with extends, however, could you not use delegate to work around that?
No, delegate can't be used for event handling. If you put a delegate DamageModifier struct inside another struct, that doesn't accomplish anything useful. You still can't move the events into the parent struct, they still need cyclical references to access data from one another.

Quote:
Originally Posted by Anitarf
I've seen some people have been enthusiastic recently about the module-based coding style, but I still prefer the multiple struct approach myself.
Extends is not supposed to be used just to add events to units, it is for specializations of object-types: for example, a specific kind of buff. (It took me a while to realize this, but there is a reason some of my old interface-based systems ever saw the light of day, it is because they were so impractical to use.) It absolutely makes sense to have events from multiple sources within one struct. Take this for example:
Expand JASS:
Without modules, the BuffSystem would have to support periodic events and damage detection on its own, which is not modular at all. In fact it's horrible and leads to 2000 line monolithic systems. If you thought that separate structs were a good idea, why did you include damage detection support in ABuff? You could have used a separate struct for those events.

Here's what it would have to look like without modules (this is painful to code):
Expand JASS:
At 32 lines vs 54 lines (excluding whitespace), it winds up taking almost twice as many lines of code.

Quote:
Originally Posted by Anitarf
A damage modifier, for example, makes more sense to me as a struct itself (which can then be a member or even a delegate of other structs) than a property/module of any struct.
A damage modifier is not anything but a unit event that returns a value. Taking this position to the extreme, we would see that any event can be handled using an interface. Why is it that no one uses inheritance for things that can be handled with function interfaces? It's because example A makes way more sense than example B:

Example A:
Expand JASS:
Example B:
Expand JASS:
The above example is lame, because it shows the improper use of extends just to bind events to a unit. Systems that do this become a pain in the ass to use in conjunction with other systems that do the same thing because they are mutually exclusive from the same struct.

Anyway, whether you want to change the basic way the system works is up to you, it is still approvable either way once the other issues are dealt with.
grim001 is offline   Reply With Quote