BJ vs. No-BJ (Get your mind out of the gutter)

[emjlr3]

whos belittling who? im lost

in any case, Daelin, and others who submit spells for contests/ acceptance at sites, follow a standard called JESP, which allows non JASS users to easily implement and customize spells, which is where the wrappers come in, which you spoke of

in his own map, im sure Daelin doesnt followthis standard for himself....

in anycase, point taken, however it seems liek were making seperate points, incase you hadn't noticed

there are jsut a few things that get me with bjs.....for example...

function IsUnitAliveBJ takes unit whichUnit returns boolean
    return not IsUnitDeadBJ(whichUnit)
endfunction

function IsUnitDeadBJ takes unit whichUnit returns boolean
    return GetUnitState(whichUnit, UNIT_STATE_LIFE) <= 0
endfunction

silly blizzard

another, like posted ealier, check the texttag bjs....they are just terrible, they really give you the run around

 

[Luth]

whos belittling who? im lost

Most recently, Daelin was impolite, at best, but that was merely the proverbial "straw". For months now, I read again and again, one person besmirching another's works for using non-natives, or globals, or "GUI-JASS". I dont criticism of one's works, but it often turns into an "I'm better than you" post, which does irk me quite a bit. Rather than rebuttle a "Yes you are" with a "No I'm not", I thought I ought have something a bit more inarguable, such as test results and imperical evidence, behind my argument. It seems, though, that a few are unwilling to accept this as well, which I didnt expect. Though, I often underestimate pride and emotion on the internet.

follow a standard called JESP

I've never heard of it. If its been posted on this site, then I've been ill fated, as I must have consistantly overlooked it. Do you have a link where I can overlook this standard?

As for IsUnitAlive and IsUnitDead, true their redundant wrappers above a central native, but like many other functions, and most wrappers, it does make the code easier to read, at least to me.

if( IsUnitDeadBJ(U) then  /*do whatever*/ endif

reads a lot faster than

if( GetUnitState(U, UNIT_STATE_LIFE) <= 0) /*do whatever*/ endif

Is it slower? Yup. Measurably slower? Nope. Should it be mocked if seen in use? Certainly not. I will consistantly use IsAlive and IsDead instead of GetUnitState, as it makes reading triggers that havent been read for months all the easier to read and modify.

As for the TextTags, it seems that the BJs give you an easier method of sizing, doing some of the fundamental calculations for you, or splitting the location, etc. While you certainly can do all that work yourself, if it pleases you, I would certainly have written a wrapper to those functions if they didnt already exist. Likewise, you could write

local integer Val = GetSomeValue()
if(Val < 0) then
    set Val = -1 * Val
endif
// do whatever

But I'd be much more apt to write

local iteger Val = Abs(GetSomeValue())
// do whatever

Its ease of use, same as with the TextTags, it seems to me. I do similiar on all my production projects: the very first step is writing an API or wrapper for math, physics, sound, IO, and graphics libraries so that we can later write code that is smaller and includes more functions (and layers of functions). It makes things easier to write, easier to read, and easier to change later.

 

[SFilip]

> If its been posted on this site, then I've been ill fated, as I must have consistantly overlooked it. Do you have a link where I can overlook this standard?
its barely even mentioned on this site...would be nice if we could make a forum/topic for it with vex's permission.
anyway here is the JESP standard manifest

 

[Luth]

Thats a nice, sound little document. It also gives reason to D's bit of hypocracy about wasting function calls.

Is this JESP mainly for distributing spells to others? Does it have any advantage to the scripter himself? It reminds me a lot of commenting procedures on some of the game teams we work on. A pain in the arse, when moving from one style to another, but useful when some know-nothing has to come in and work on your code.

 

[SFilip]

the main advantage in my opinion is actually making non-jass users friendly mui spells - something good that everyone can use and modify with ease.

 

[corvusHaunt]

I don't care either way. I don't use them - it's not because I think my script is superior to anyone else's who decides to use BJ functions; it's because I personally like it that way. And I'd never belittle anyone for using BJ functions; sure, I might prod them a little to get them to use natives, or a different solution, and I'd definately nag them about leaks and things....

 

[Daelin]

Most recently, Daelin was impolite, at best

Oh yeah, I was totally impolite and I am soooo sorry about it. So that you know, the integer stuff was a mistake because I oversaw it a a group between the locals. But go ahead, use it as a counter-argument. Not that I didn't confirm that I was wrong with that before you even posted. I never said that "I'm better than you" and I never suggested that. If you understood that then it's not my problem, because that wasn't my intention. But you can't just reject everyone's opinion when people come with good arguments (refering now especially to Vex and SFilip).

one person besmirching another's works for using non-natives

Look Luth, I never bescmirched anyone when it came to using BJs into their codes. It's impossible to prevent them when you are writing in GUI. The only solution is to switch to JASS. And as for GUI->JASS conversions, hell, I encourage them as a first step in learning JASS (for those already knowing GUI). But I also encourage to get rid of them in time. Too bad my "JASS Basic Tips" tutorial was deleted. It had a chapter about BJs there too and how to avoid using unecessary ones. And yes, I know there are some useful BJs there. As an example, a lot of people use "TriggerRegisterAnyUnitEventBJ" because registering an event to a trigger rarely occurs, making it so useful and easier for others (and yourself) to read the code.

I will consistantly use IsAlive and IsDead instead of GetUnitState

I wouldn't recomment either but it's up to you. I was lately taught that they can both get really messy and buggy. You can increase a dead unit's life though it will not revive it. That way, the "IsDead" will return false because unit's life is greater than 0, even though it is dead. The best way to test if an unit is dead is doing "IsUnitType(unit, UNIT_TYPE_DEAD)==true". Yes, you need to use IsUnitType in a comparision or else it will not work correctly. It is a JASS bug.

Why use, taken from your own map,

constant function ManaPulse_SpellRaw takes nothing returns integer
    return 'A001' //main ability rawcode
endfunction

Simple, because I made the spell for public use. It makes it so much easier to implement! And that's why I made the function constant, so that it works faster. Into my own project, I will not use configuration functions, exactly because I want to avoid any possible source of slowness.

Yes, I have. And even under worse case scenarios, provided by Emj, the extra function wrapper did not affect overall performance at all. Not one bit.

Depends on what computer you tested it. Of course, with the latest computers the difference is unnoticeable but keep on mind that there might be people who still use Pentium 3's. What do you do with them? Tell them to buy a new computer? Of course not, you try to make your spells more efficient so that they work flawless on their PCs too. And I'm speaking from personal experience. I remember that when I got involved into spellmaking I had a Celeron at 533Mhz. Sounds almost impossible to run warcraft on it, but surprisingly I finished both RoC and TFT campaigns. However, spellmaking was a bit difficult because I noticed lag very frequently.

And don't take me wrong, I'm not trying to say "look here, I'm better than you". NO! I am trying to prove a point. Try making those tests on a 800 Mhz and then tell me what were the values of your tests. Maybe not significant enough for a single tests, but for a greater map it will be.

~Daelin

 

[Luth]

See, I didnt want to make this personal. So I'm not gonna. Discounting that, there's not much to reply to in your post... some bits that dont make sense, some points already covered (and I hope we're all quite done repeating ourselves)...

As for running the tests, I dont have an 800MHz handy. The slowest I have is a 1.1 GHz, a laptop, and a linux system. If I could have tested on the linux, I would have, but the other two were my test computers. I imagine on "gaming rigs" the scores would have undoubtedly been too close to find any discrepency at all.

 

[AceHart]

"The interplay of ideas and the oblique uses of knowledge are often of extraordinary interest."

Unfortunately, that doesn't apply to this thread.