| |
Slammer
Registered: Feb 2004
Posts: 416 |
Kick Assembler Thread 2
The previous thread took a little long to load, so this is a new fresh one.. |
|
... 592 posts hidden. Click here to view all posts....
|
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
@Ruk:
You're trying to make a boolean and (&&) of false (the result of containsKey) and null (the result of get), which doesn't make sense.
Your function seems to do the job, but you could also do it like this:
.const booleanOption = hashtable.containsKey("booleanOption") ? hashtable.get("booleanOption") : false
|
| |
ruk
Registered: Jan 2012
Posts: 43 |
Sure, np, but I've gotten used to lazy evaluations in boolean expressions.
Thing is, if containsKey() == false the '&&'-operator shouldn't evaluate the term to the right since the whole expression is bound to be false.
It just struck me as odd that Kickass complained.
|
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Ah, so that's what you meant. Wasn't familiar with the term lazy evaluation. Guess KickAss doesn't use it, but I guess it would be smart from a performance viewpoint. |
| |
tlr
Registered: Sep 2003
Posts: 1732 |
It's also commonly known as "short circuiting" operators. It is well defined for many C-like languages. I would guess it applies to Java as well. |
| |
Frantic
Registered: Mar 2003
Posts: 1634 |
Can't remember last time when I encountered a language that did NOT use lazy evaluations. Indeed something that I have also gotten used to using. |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
KickAssembler will probably support short circuiting in one of the future versions, as it converges towards the Java/C++ style. The idea is that, the more ways KickAss Script is similar to C++/Java, the easier it is to learn since you can use what you already know.
Frantic: Don't know if its still the case, but Visual Basic?
Once I had to work in Visual Basic for a shorter period of time and one of the things I really missed was short circuiting, which really ruled out a lot of ways to express things. So I fully understand why you miss it.
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
i think this is a bug =) this works:
.import source "../framework/framework.asm"
this gives an error:
.if (1 == 1) {
.import source "../framework/framework.asm"
}
flex pass 1
.import source "../music/music2.inc"
.if (1 == 1) {
.import source "../framework/framework.asm"
^
Error: Unknown import type 'source'
whatthehell ? :)
edit: lol. i already reported it a while ago =) and i still think its an error, its totally not how you'd expect it to work and it makes more complex stuff almost impossible to do. too bad really, things like that drive me back to ca65, despite the many nice features in kickass :/ (.if always adding a scope around the enclosed block also makes it a lot less useful than it should be, unfortunately) |
| |
ruk
Registered: Jan 2012
Posts: 43 |
I think what we're lacking is preprocessor stuff à la C since things like conditional compilation can't be solved by the scripting facilities of KickAss.
At least this is what I suspect.
So, I propose the introduction of #if, #ifdef, #ifndef, #else, #elif and #endif directives. It would solve many things, at least for me. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Found a workaround that might do the trick...
.import source 1 == 1 ? "framework.asm" : "emptyFile.asm"
It can't use vars or anything fancy in the condition though, except for command line args.
.import source cmdLineVars.get("importFramework") == "true" ? "framework.asm" : "emptyFile.asm"
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
yes, indeed. for the scripting and table generating stuff the current set of features is great.... for anything else not so much. |
| Previous - 1 | ... | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | ... | 61 - Next |
