For Lax

iluvseq · Post by **iluvseq** » Mon Apr 19, 2004 2:24 pm

lax wrote:Get the latest zip.

${Me.Name} is a string
Tell me how to parse this:
/newif Supercallifragilisticexpialadocius /echo TRUE

/newif in any zip from 20040415 and later will not behave the way you say.. the notice in this forum says please do not post bug reports from old zips. locking thread

A) I was using a zip I DL'ed on 04/16, which was after the supposed "/newif" change about it barfing if it couldn't parse the conditions. I read that change entry on the 15th (yes, I read these boards multiple times a day, including the manual and changelogs) Since there were no commented changes to /newif in 04/17 or 04/19, I didn't think a new version would matter.

b) to parse /newif sldfskldfhsdjfhsd /echo TRUE, you may have to change the logic of your variable replacement. I'm not sure. But I'd say you shouldn't replace ${SomeString} with the contents of the string, except where it specifically should be (ie: inside "" or on an /echo line, which has assumed quotes)

/newif ${Me.Name} {} or any other ${} that is a string, should be simply checked for definition. You shouldn't interpolate the value as that is almost never what is wanted. When would it be? when it's inside "" or on an /echo line. Otherwise, it doesn't make sense.

The latest zip still does the "wrong thing" when it comes to this case, but it does barf with a warning.

Lax, I know you are busy and have a short fuse regarding "newbies" and idiots who don't read the manual and ask stupid questions or whatever, but man oh man, you are lock happy.

Locking a thread with "get the latest zip" is a knee jerk reaction and should only be used for seriously stupid questions like "MQ doesn't work since the patch"

However, when someone posts a valid bug, one that no "changelog" states has been fixed, telling someone to "get the latest zip" and locking the thread is simply assinine and rude.

Especially when you ask a question in your post. How am I supposed to answer your question in a locked thread?

There is a behavior that is wrong and counterintuative. I pointed that behavior out. Lets DISCUSS the situation and come to a solution, not just slam the door and lock threads, ok?

Lax · Post by **Lax** » Mon Apr 19, 2004 2:38 pm

It's a rhetorical question.

I CANT parse /newif jflkgfdjklgfdlgkjd /echo true

iluvseq · Post by **iluvseq** » Mon Apr 19, 2004 2:58 pm

True.

So don't.

However, the problem can be solved another way.

You should ONLY convert ${somestring} to it's actual value in two cases (that I can think of)

Case one: When it is inside quotes. ie: "${Me.Name}" should convert to "iluvseq"

Case two: When it is inside "implied quotes" ie: /echo ${Me.Name} should convert to /echo iluvseq

You should NEVER convert ${somestring} to it's value anwhere else that I can think of.

So, that way, when you encounter /newif ${Me.Name} {} you completely skip the variable interpolation step.. There is no implied quote or true quote, so it's not needed.

Instead, you look at ${Me.Name} as an entity and evaluate it for TRUEness. Since it is a string, the way to check for TRUEness is to see if it is defined as somthing other than "" or "NULL".

ie: /newif ${Me.Name} {} should be equivalent to /newif ${Me.Name.NotEqual["NULL"]} {}

Currently MQ2 interpolates ${String} variables in place whenever it encounters them, and this is, in my opinion, invalid behavior.

Lax · Post by **Lax** » Mon Apr 19, 2004 3:10 pm

Call it invalid call it what you like, but the parsing is done long before /newif even touches it. It's a universal system, /newif doesnt specially handle the parsing. What you're calling invalid is how the system is supposed to work.

Me.Name is always going to be a name, or NULL.. how are we supposed to, across the board mind you, determine that having any random string is supposed to mean true?

This is why I locked the thread.

ml2517 · Post by **ml2517** » Mon Apr 19, 2004 3:58 pm

Just use:

Code: Select all

/newif ${Me.ID} {
    /echo Yes I exist
} else {
    /echo Apparently I'm a Nobody
}

It really isn't that hard to do. If you truly are working with something that outputs text only how hard is it to tack on a .Equal[], .NotEqual[] or .Find[]?

Code: Select all

/newif ${String["@a"].Equal[Chump]} {
    /echo Yes I am a chump.
} else {
    /echo Apparently I'm not a chump.
}

iluvseq · Post by **iluvseq** » Mon Apr 19, 2004 4:15 pm

You are telling me that you always parse ${Me.Name} to whatever it's value is, no matter the context?

How about in phase 4, when you convert all @variables to ${variables}

How's the parser gonna like this:

Code: Select all

/declare ${foo} string
/varset ${foo} "iluvseq"

Since you parse ${foo} to it's value, regardless of context, that will parse to something like /varset "" "iluvseq"

Not good.

You can't just blindly interpolate ${} values. Integers, sure. Strings? no way.

Only inside of "" should ${somestring} be replaced with it's value.

It hasn't been much of a problem yet, but I am willing to bet that you'll find all kinds of nasty problems once you convert @vars to ${vars} unless you redefine your parsing rules for strings.

Look at other programming languages, especially scripting languages. You'll find that nearly all of them will behave as I have described.

There is a reason for this.

iluvseq · Post by **iluvseq** » Mon Apr 19, 2004 4:17 pm

Lax wrote:Me.Name is always going to be a name, or NULL.. how are we supposed to, across the board mind you, determine that having any random string is supposed to mean true?

In every other scripting language on the planet, a string is "true" if it has a non-null value.

In other words, if a strings value is NULL or undef or "" (the null string) then it is FALSE, in all other cases, it is true.

A few languages (PHP I think) also define a string "0" as false, but most would consider "0" as a string to be true.

Lax · Post by **Lax** » Mon Apr 19, 2004 4:28 pm

Somehow i doubt that "every other scripting language on the planet" considers a string to be true if it has a non-null value.

Our discussion is over, use numeric comparisons.

Botmaker · Post by **Botmaker** » Mon Apr 19, 2004 5:18 pm

this should work too

Code: Select all

/newif ${Bool[${Me}]} /echo hello, ${Me}

iluvseq · Post by **iluvseq** » Mon Apr 19, 2004 5:31 pm

Ok, Lax... Don't say I didn't warn you. You'll have to adjust the parser for ${} variables.

At that point, you will probably keep your head in your ass and refuse to support TRUE or FALSE for strings based on definedness, but your arguements against it will no longer apply.

Lax · Post by **Lax** » Mon Apr 19, 2004 5:43 pm

No, the parser will not have to be adjusted for ${} variables. How about you get YOUR head out of your ass instead of trying to tell me the system isnt going to work the way it has been planned, is working, and will be working. Where the fuck did you warn me that i would have to adjust the parser for ${} variables? I would like to see ONE instance that it needs adjusting to handle. The instance of /newif ${Target.Name} { is NOT one such instance because we already offer string comparisons AND methods to determine if you have a target (this is not one of them).

How about you get a fucking clue and learn how to work with numeric comparisons instead of slinging mud when you dont know what the fuck you're talking about

iluvseq · Post by **iluvseq** » Mon Apr 19, 2004 6:03 pm

Listen, I haven't slung any mud, and even tried to be nice to you.

You are the one who started off by locking threads and being a prick to me.

For your information, I KNOW how to use numeric compares. Thats NOT the point.

The point is, IF the parser blindly replaces any ${} string with it's value (As it seems to do right now) then what happens when you have the very simple (and I am sure common) construct:

Code: Select all

/declare ${mystring} string
/varset ${mystring} "foo"

How can that possibly work with the current parser that will blindly replace ${mystring} with it's value?

And if the parser DOESN'T blindly replace ${} string variables with their value, then what is wrong with allowing it to determine TRUE/FALSE based on definedness, just like Perl, PHP, visual basic (censor: i'm an idiot; please ignore me) and any other scripting language I can think of?

Is it "wrong" to require numeric comparisons? Probably not. However, for pretty much anyone who is actually a programmer and not learning how to code simply from Macroquest, not allowing constructs like /newif ${string} { is counter-intuative.

That was my only point, and I really don't care if you decide not to impliment it. However, you REALLY need to stop being such a rude prick to people. I've been on these forums for a long time, I've contributed quite a bit to the Item structure. I take the time to RTFM and do my homework before I post questions or concerns. I don't deserve your shit.

Plazmic · Post by **Plazmic** » Mon Apr 19, 2004 6:13 pm

Because you will

Code: Select all

/declare mystring string
/varset mystring "some string"
/echo ${mystring}

ml2517 · Post by **ml2517** » Mon Apr 19, 2004 6:14 pm

How about you let him actually code the new variable stuff before criticizing it?

Plazmic · Post by **Plazmic** » Mon Apr 19, 2004 6:26 pm

Missed something in my last reply:

Is it "wrong" to require numeric comparisons?

It's 100% ACCURATE to require numeric comparisons.
In all languages I know of your string comparision you refer to is handled as:
Is this string not NULL (in math that means thisstringspointer!=0)
Scripting languages sometimes also compare that the first character of the string isn't a null terminator (in math that means thisstringpointer[0]!=0)
Notice how both of those comparisons are MATH comparisons (not equal to 0)

I thought Lax wrote /newif to be "0 = false, anything else = true", but that would have parsed "/newif somestring /echo TRUE" in a manner consistant with what you want, without bothing to interpret the variable before replacement.