()?():() operator?

Does LSL support the ? operator from C? For example, can you do:

iValue = (sSomeString == "abc") ? TRUE : FALSE;

which would set the value of iValue to TRUE if sSomeString equals "abc", otherwise it would set iValue to FALSE. I know you can get around this with an if statement, sometimes this is just a bit more compact and faster in its operation.

Thanks,
Tigs

Nope. Use an IF statement.

I asked kelly linden about this today actually, not at the moment. Although it may be worth asking one of the LSL lindens (Don, Cory, etc.)

-Adam

I always found that ? thing to be the most confusing conditional ever.

on the discussion of operators. What dose & do in sls? I'm asking because some of the examples listed at wiki list if statements in the format of (value & static value). I would think & as an operator would return true or false. True being returned, only if value a and b do not contain the value 0.

& is bitwise AND.

i.e. if(this AND that){code}

if(this & that){code}

(sob)

I miss my ternary operator! ?:, how I long for thee and thy space-saving, newb-confusing semantics!

I found that it was very confusing, also, until that one day when it suddenly "clicked." Now I use it for quite a few things.

The other developers on my team, however, hate the fact that I use it, because it hasn't quite clicked for them yet, and they have a hard time following logic that uses it some time.

Grim,

I just drew it out on a whiteboard for people one day:

foo = (if) ? (then) : (else);

Seemed to clear things up pretty well.

Yeah, when they see it that way, nobody has any trouble with it.

But when I've got them nested 4 deep in a parameter list, or I write a one-line recursive function that uses a ternary operator, their eyes glaze over and it usually turns into a 15-minute "What does this do?" session, or more frequently, I end up having to do their modifications.

Which may all be changing soon. I'm going to be moving out of the dev team to be a full-time architect/analyst. No more code-monkey work for me! Yay!

**Edit: I can't speel

What he sai- *eyes go donut-y*

Thats an excellent way to get your ass kicked on my team

Yes, I know what they do and how to use them. No, I dont want to wade through 4 unreadable lines of code trying to figure it out. Thats poor coding practice and not impressive at all

-AP

Pfft

They make perfect sense to me.

I have to agree with Taggy here. The ternary operator is best used simply, if at all.

In java, I use it to simplify stuff like:
if (str == ""
return null;
else
return str;

Using ternary actually makes it easier (IMO) to understand:
return str.length() == 0 ? str : null;

I dont even want to *think* about nested ternary operations. Ew.
==Chris

Using ? may look good and profesional, but its just confusing... i've always sticked to just plain old "if".

Alot easier to read when dechipering someone's code, too.

Blah,
I just discovered there is now switch/case statements for LSL either. Can you say, "Lots of 'if' statements?"

Tigs

if is better for the soul anywho.

Of course, because you wrote them. I can write cool unreadable code too. However, the point of team development isnt to demonstrate to each other how well we can make cool one line algorithms. The idea is to create code that is easily maintainable and tracable by anyone on the team.

It's cool to swap neat code tricks by email for cool points, but having to deal with uncommented silliness in the CVS repository is most assuredly uncool.

I'll hex it out with anyone for fun, but when it comes to maintaining code that I'm not particularly interested in, I really could care less about clever tricks. I just want to get the damned report generated for the boss so we can all get on to more interesting stuff.

Stumbling across ternary operators in the course of doing so merits an automatic wedgie for the dingleberry who did it.

-AP

I posted The Big Secret in another thread, but I'll repeat it here: Code is not for computers to read, it is for people to read. Computers read assembly and bytecode, people read code.

If your cow-orkers can't follow your code (and they're not incompetent) then your code is wrong.

lol

Actually, I don't really use them that much. I was just tweaking a few noses.

I do, however, do a lot of database programming on legacy VB6 apps and newer C# apps. I don't know what dipshit at Microsoft decided that a C# null and a DBNull should be so freaking difficult to translate back-and-forth, but I'd like to strangle him/her. This is the most common case where I use the ternary operator in an argument list. i.e.:

cmd.Parameters.Add("dateTimeParam", DateTime.MinValue == dateTimeValue ? DBNull : dateTimeValue);

Otherwise I find that the code forks so much that it's extremely difficult to read.

**Edit to add: If you look back at the same thread that Wednesday is referring to, you might take note of my reference to self-documenting code, also.

Well, in that case it makes sense to use it I agree. I was more referring to nested boodles of unreadable code

Anyway, I was pretty much just razzing ya

-AP

LOL. I've worked for team leaders who took extreme exception at concise, highly readable, very logically laid out code containing a
conditional expression .... because it allegedly messed up their beautiful 30-deep class hierarchies. Pots and kettles come to mind!

Dogma is .... just dogma.

A good software engineer uses multiple forms of expression, each one where it is applicable. Fortunately, I do the interviewing now.

i'm a [lazy] programmer and i don't like having to write out 4 lines of code when a single line of code would do the job.

example:
without (test?true:false)

if (a)
    llMessageLinked(0,1,"monkeys","");
else
    llMessageLinked(0,1,"cabbits","");

with (test?true:false)

llMessageLinked(0,1,(a?"monkeys":"cabbits"),"");

lets complicate things...

llMessageLinked(0,1,(a?"monkeys":"cabbits"),(b?"good":"evil"));

there would be a number of ways of writing that out... none of them nice.

if (a)
{
    if(b)
        llMessageLinked(0,1,"monkeys","good");
    else
        llMessageLinked(0,1,"monkeys","evil");
}
else
{
    if(b)
        llMessageLinked(0,1,"cabbits","good");
    else
        llMessageLinked(0,1,"cabbits","evil");
}

this is ugly and cumbersome not to mention a waist of resources.


or

string c;
string d;
if (a) c="monkeys";
else c="cabbits";
if (b) d="good";
else d="evil";
llMessageLinked(0,1,c,d);

this second solution is what i end up doing but i don't like it as it requires me to declare variables.

sorry but a single line of code over a half dozen plus lines is better. if it's confusing add a comment.
speaking of comments could we get C comment support? ( /* comment */ )

/* commented out */ would be wonderful. It would save time. Every time I have to debug code I pray for /* */. Plus it reduces chances of user error.

One line if statements may look cute. But how often do people chose animal, and only offer two choices? What happens if you want to offer 52 different animal type? And what if you need to use that if statement more then ones?

Plus an if statement in the middle of out put is kind of hard to read. Especially if it multiple if statements imbedded.


This is what I would do.
global list speciesTypes = ["cat","dog","fooBar"];
global list Heven = ["good","Evil"];

animal(integer animal, integer Heven)
}
string species;
string status;

species = lllist2String(speciesTypes, animal);
status = lllist2String(statusTypes, Heven);

llSay(0, "The " + species + " is " + personality + ".";
}

it may not look as pretty. But it gives allot of room to grow. But then again they're is always some thing simple like.

llSay(0, "The " + species(animal) + " is " + status(type) + ".";

Or maybe even

llSay( 0, "the cow says " + op( 0, "string for True", "string for Faluse" ) );

I know it's not what you want.

That provides some of the conciseness of the conditional expression, but not the efficiency since function calls are likely to be pretty expensive. Or, if the construct is only syntactic sugar rather than a real function call, then it gains nothing but confusion over actually adding a real conditional expression into the syntax.

However, I don't think there was a truly serious suggestion being made to add such. It's merely in the "wouldn't it be nice" category because LSL is a bit poor on the conditional front.

Far more important for SL would be any additions that improve the efficiency of the language. Arrays would bring one such massive improvement since indexing uses no CPU to speak of. Some nice simple arrays with predeclared fixed lengths would be very simple to implement and would reduce server loading if people got into the habit of structuring code as command dispatch tables instead of filling them with snaking if's. A safe externalized form of function pointer would be needed for dereferencing to the selected function to dispatch, but that's simple to implement safely. OO zealots could even implement class hierarchies and simple inheritence using this, without turning the language itself into a highly inappropriate OO one.

Full dynamic hash-indexed associative arrays would be a lot "nicer" of course, but that's asking a lot as it wouldn't be a trivial addition. Also, the efficiency payback is tiny compared to real array indexing, because hashing only becomes a winner for large datasets, which we rarely see owing to our execution limits and the natural fine granularity of the state-machine environment.