• Listen to a special audio message from Bill Roper to the Hive Workshop community (Bill is a former Vice President of Blizzard Entertainment, Producer, Designer, Musician, Voice Actor) 🔗Click here to hear his message!
  • Read Evilhog's interview with Gregory Alper, the original composer of the music for WarCraft: Orcs & Humans 🔗Click here to read the full interview.

Turn boolexpr back into code?

Status
Not open for further replies.
Level 12
Joined
Feb 22, 2010
Messages
1,115
Well, not exactly sure what "boolexpr back into code" means, since they exist seperately.If you use Condition on a function, the function still can be used somewhere else.

Are you asking about getting the function which boolexpr made of?
 
Level 15
Joined
Aug 7, 2013
Messages
1,338
Are you asking about getting the function which boolexpr made of?

Yes, this exactly.

JASS:
local code c = function foo
local boolexpr bx = Condition(c)

//now I want to turn bx back into function foo
local code d = Function(bx)
 
Level 15
Joined
Aug 7, 2013
Messages
1,338
Ah I see.

My use was limited--basically I had a function which took a code as argument, but then stored it as a boolexpr variable. I had another function which created a deep copy of this struct, but I couldn't call the first function because it wanted code and not a boolexpr.

I see now I should have just made the variable a code instead.

However, another interesting thing I observed. Normally boolexpr requires its function returns a boolean value. However when I did this, it was ok for my functions to return nothing.

JASS:
function foo takes nothing returns nothing
endfunction

function bar takes code c returns nothing
  local boolexpr bx = Condition(c)
endfunction

function bar2 takes boolexpr bx returns nothing
endfunction

...

call bar(function foo) //this works for me!!! (why?)

call bar2(Condition(function foo)) //this doesn't compile

Any reason why?
 
Last edited:
Level 23
Joined
Apr 16, 2012
Messages
4,041
There is no way to find if function inside code variable is returning boolean or not during compilation. Dont use code variable, you cant have array of codes, use boolexprs for.everything, and only except code in register/unregister functions
 
That is actually the fault of PJASS. If you were to do this in the standard editor:
JASS:
function Sample takes nothing returns nothing
endfunction

function Test takes nothing returns nothing
    call Condition(function Sample)
endfunction

It would not throw an error. However, if you have the latest PJASS (included in JNGP), it will throw an error. In that regard, PJASS is not quite 1-1 with the actual syntax checker. It mistakenly reports that the function must return a boolean. However, it doesn't perform deep checks. That is why your function does not throw an error--PJASS only checks boolexprs that have direct function input as an argument. But once you add a layer, such as a parameter "code c", PJASS does not check whether the function returns a boolean.

Off-topic/history: When patch 1.24 came out, effectively killing the return bug, PJASS had to be updated to throw errors when a function did not properly return what it was supposed to. Otherwise, code would parse just fine while saving with JNGP, but it wouldn't load in-game. The patch added a buttload of type-safety. Implicit conversion wasn't supported anymore (e.g. returning "1" as a real would throw an error. It would have to be "1." or "1.0"). Blizzard even had to update their blizzard.j since it relied on implicit conversion. I'm guessing PitzerMike added the "boolexpr function must return boolean" in response to that type-safety, without testing whether it was an actual rule. PJASS could be updated to fix that, but there isn't much point to that. It saves a few lines of code, but so many people are using that version of JNGP, that it would make scripts that don't return boolean throw an error on older versions.

@edo: It actually could be possible to determine whether a function is returning boolean, but it would require deep checking. Since code can't be arrays and code can't be arbitrarily created, you could just follow pointers to code and determine whether it is valid input. It is pointless, but it is possible. :p
 
Level 15
Joined
Aug 7, 2013
Messages
1,338
Ah thanks for the clarification Purgeandfire.

So if the function actually returned a value that wasn't boolean (e.g. integer), the compiler would complain regardless?

Also, is there any difference between a boolexpr that actually returns nothing, which apparently is possible, because my callbacks were working fine in testing, than a boolexpr that correctly returns a boolean?
 
Also, is there any difference between a boolexpr that actually returns nothing, which apparently is possible, because my callbacks were working fine in testing, than a boolexpr that correctly returns a boolean?
Except for what has been pointed out, no there isn't any. The only noticable difference is the return argument, in first it's void, in second it's bool.
 
Status
Not open for further replies.
Top