New Operator: <>

Page: 1 2
ID:134789
 
Sep 12 2005, 4:04 pm
I think the "<>" operator should be used as Not Equal To, such as

if(src.A <> 15)
src<<"You lost."
Sep 12 2005, 4:06 pm
Um, do you know about the ! operator, or known as the "Not" operator. So if(A != 15) world << "Yay, A isn't 15"
Sep 12 2005, 4:07 pm
Strawgate wrote:
I think the "<>" operator should be used as Not Equal To, such as

if(src.A <> 15)
src<<"You lost."

You can use the != operator to do this very thing.

if(src.checkVar != magicNumber) src << "Check failed!"


~>Volte
Sep 12 2005, 4:41 pm
Sep 12 2005, 5:55 pm (Edited on Sep 13 2005, 5:49 am)
In response to YMIHere
I've always wondered what priority this operator gets in relation to '!=', anyone know?
Sep 12 2005, 6:00 pm
In response to IainPeregrine
It's the same as !=.
Sep 12 2005, 10:31 pm
If it doesn't exist, define it.

#define <> !=


I already use that for && and ||

#define and &&
#define or ||
Sep 13 2005, 3:31 am
In response to Jp
That's a horrible habbit.

On par with smoking.
Sep 13 2005, 8:57 am
Isn't there already a <> operator, and doesn't it already do that? I roughly translate it to "if it isn't that." Unless spies altered my DM help files and defined the operator in my code.
Sep 13 2005, 9:36 am
In response to Repiv
Repiv wrote:
That's a horrible habbit.

Why?
Sep 13 2005, 1:18 pm
In response to Repiv
Repiv wrote:
That's a horrible habbit.

Like spelling "habit" with two Bs? :-)

http://gazoot.byond.com/bbash/?quote=136
Sep 13 2005, 2:20 pm
In response to Repiv
Why? Isn't the whole point of #define to either make it so that you are more comfortable with the code or to make the code smaller?

I don't see how it can do any harm at all.
Sep 13 2005, 2:56 pm
In response to PirateHead
It might confuse people who are working in a team, or produce inconsistencies in the code (some people using OR and AND, other using && and ||). Plus, I dunno...in ActionScript, AND and OR are deprecated in favour of && and ||.
Sep 13 2005, 3:34 pm
In response to Jamesburrow
Jamesburrow wrote:
Why? Isn't the whole point of #define to either make it so that you are more comfortable with the code or to make the code smaller?

Not always. There's also using #define to create constant variables. #define generally makes it easier to make changes to constants.
Sep 13 2005, 6:45 pm
In response to Audeuro
Audeuro wrote:
#define generally makes it easier to make changes to constants.

Nonsense. Since when is this:
#define BLAH 15

easier to change than this?
var/const/BLAH=15


If you want to go and make new operators like that, I say go ahead. =)

Elation, I don't know much about ActionScript, but I suspect that the "and" and "or" operators were bitwise operators, like "&" and "|". In that case, you'd normally want to use the logical operators, && and ||, which are generally safer for what "and" and "or" are otherwise usually used for (logical operations).
Sep 13 2005, 8:59 pm
In response to Elation
Elation wrote:
It might confuse people who are working in a team, or produce inconsistencies in the code...

horsepuckey- if the 'team' is all on the same page, and your design docs define what the standards are in the code, then there should be little trouble.
Sep 14 2005, 9:07 am
In response to Crispy
Elation, I don't know much about ActionScript, but I suspect that the "and" and "or" operators were bitwise operators, like "&" and "|". In that case, you'd normally want to use the logical operators, && and ||, which are generally safer for what "and" and "or" are otherwise usually used for (logical operations).

Ripped straight from the ActionScript help:

Deprecated Flash 4 operators overview
The following table lists Flash 4-only operators, which are deprecated in ActionScript 2.0. Do not use these operators unless you are publishing to Flash Player 4 and earlier.
Operator                       Description

not                            Logical NOT
and                            Logical AND
or                             Logical OR


Sep 14 2005, 10:26 am
In response to Crispy
Crispy wrote:
Audeuro wrote:
#define generally makes it easier to make changes to constants.

Nonsense. Since when is this:
#define BLAH 15

easier to change than this?
var/const/BLAH=15


In general, people use #define for constants. I'm not talking about in JUST byond, but also in other languages, like C++, etc. In C++, you CAN do "const (type) (varName);" but from what I've seen, a lot more people use #defines for constants. Example, taken straight from my engine:

#define LOG_WARNING 0
#define LOG_ERROR 1
#define LOG_DEBUG 2
#define LOG_INFO 3

// I have a function that takes an int as the first param, and a const char * as the second.
// It's called "Write"

// So, later on, I'll do Logger->Write( LOG_INFO | LOG_DEBUG, "Engine Initialized" );


For loggers, this is the way I've seen them done.

Also, there is other situations where I've seen people use const instead. Like, where the type is not an int or a char.
Sep 14 2005, 1:01 pm
In response to Crispy
Nonsense. Since when is this:
#define BLAH 15

easier to change than this?
var/const/BLAH=15


Unfortunantly until DM has cool compiler functionality that preprocesses expressions which can be computed at compile time you can't do anything like this with const variables.

var
    const
        CNONE = 0
        CBLOCK = 1
        CLINE = 2
        CBOTH = CBLOCK | LINE  //This isn't constant though it really should be.


But you can easily do this with defines. Though I do agree const variables are better since they are independant of compilation order unlike #defines however some constants you can't really represent cleanly with const because of these restrictions.
Sep 14 2005, 3:03 pm
In response to Volte
That seems like it could be redundant.
verb
  CheckThing()
    if(usr.thing == src.thing) usr << "YAY"
    else usr << "BooHoo"
//isn't that the same as
verb
  CheckThing()
    if(usr.thing != src.thing) usr << "BooHoo"
    else usr << "YAY:

Aren't those the same thing?
Page: 1 2