reserved words

ID:260857
 
Dec 31 2009, 7:33 am
It seems like the name of every built-in proc is a reserved word. Consider this example:

mob
    proc
        block()
            world << "[src] blocks the attack!"


This doesn't compile since block is a reserved word, but this doesn't seem like a necessary restriction. You might want to avoid this:

proc
    block()
        return "Not what you expected!"


If this did compile it would cause problems. There'd be no way to differentiate between the built-in block() proc and the one we defined. In the first example, the proc would always be referred to as mob.block() or /mob/proc/block. It would only be referred to as just block() if called from another mob proc, but naming conflicts like this aren't new to the interpreter. This is no more a problem than this: (which does compile)

var
    test = 1

mob
    var
        test = 2
    proc
        something()
            world << test


Another one I noticed was "length". If I create a custom data structure I cannot define a length() proc that returns the number of elements it contains. "text" is another one, but that gives a "duplicate definition (conflicts with built-in proc)" error instead of "invalid proc name: reserved word".

It seems unnecessary to prohibit so many proc names for all object types. By giving built-in procs intuitive names (most of the time) they're easy to remember, but the built-in procs end up hogging all of the good names. This forces programmers to use obscure, less intuitive names for their own functions.
Dec 31 2009, 8:03 am
There's what, 30 reserved words?

Who gives a ****? Open up a dictionary, there are thousands to choose from

Not only that, you could avoid it altogether by naming it _block().

Sheesh seriously? Complaining about 30 or so reserved words? That's hilarious
Dec 31 2009, 10:38 am
In response to Mista-mage123
Mista-mage123 wrote:
There's what, 30 reserved words?

Who gives a ****? Open up a dictionary, there are thousands to choose from

Not only that, you could avoid it altogether by naming it _block().

Sheesh seriously? Complaining about 30 or so reserved words? That's hilarious

The snide remarks were not necessary in a forum post, chill.
Despite that, he does have a point. If you have a problem with the reserved words, you can name them _proc() Proc() proC() etc.
Dec 31 2009, 11:01 am
In response to DivineTraveller
DivineTraveller wrote:
Despite that, he does have a point. If you have a problem with the reserved words, you can name them _proc() Proc() proC() etc.

In a game with dozens of object types and hundreds of procs, you might remember that the command to make a mob attack is mob.attack() and the command to make a mob run away is mob.run_away(). But will you remember that the command to make a mob block an attack is called mob.blocK() or mob._block()? Probably not.

No workarounds should be necessary because this problem shouldn't exist. It could make sense to prohibit users from declaring global procs that have the same name as built-in procs. But as I stated in the original post: with member functions there should be no problem.

For example, you can declare a member variable named world:

mob
    var
        world = "something"
    verb
        test()
            for(var/mob/m in world)
                world << m.world


This compiles and works just fine. But you can't create a global variable named world:

var
    world = "something"
// error: world: duplicate definition (conflicts with built-in variable)


Similarly, you would expect this code to compile:

mob
    proc
        walk()
            world << "[src] walks."
// error: walk: invalid proc name: reserved word


And you'd expect this code to have an error:

proc
    walk(mob/m)
        world << "[m] walks."
// error: walk: invalid proc name: reserved word


But they both have compile time errors.
Dec 31 2009, 11:15 am
In response to Forum_account
Forum_account wrote:
DivineTraveller wrote:
Despite that, he does have a point. If you have a problem with the reserved words, you can name them _proc() Proc() proC() etc.

In a game with dozens of object types and hundreds of procs, you might remember that the command to make a mob attack is mob.attack() and the command to make a mob run away is mob.run_away(). But will you remember that the command to make a mob block an attack is called mob.blocK() or mob._block()? Probably not.

Oh, you'll remember alright. You'll get a compile-time error reminding you. mob.Block() would be suitable and perfectly fine; I don't see what's so hard about it.

No workarounds should be necessary because this problem shouldn't exist. It could make sense to prohibit users from declaring global procs that have the same name as built-in procs. But as I stated in the original post: with member functions there should be no problem.

[...]

All I have to say then, I've been working with BYOND for nearly four years, and I have not yet needed to name anything accordingly like this, and all I've done since I was here is develop rpgs; the most likely to use them.

I don't see much of a purpose in this, to be perfectly honest, so I strongly suggest you start capitalizing your proc names if they're -that- important. If all else fails, find synonyms, shorten words, do what you need to do.

Dec 31 2009, 12:25 pm
From what I've heard of the code behind the compiler, this would be far more work than it would ever be worth.
Dec 31 2009, 12:27 pm
In response to Forum_account
<.< The only thing I dislike about reserved words: You can't modify them D:

client
North()

^ you can modify that or not have it in your code, so it works out fine.

but with things such as step...

proc
step(a,b,c=null)
..()
a.icon_state = c

): would require you to call
step(src,NORTH)
src.icon_state="lahdiedahdy"
.> not hard to put it after each call, but would save on file space per each :)
Dec 31 2009, 1:27 pm
In response to Leur
Leur wrote:
^ you can modify that or not have it in your code, so it works out fine.

You're talking about proc overriding, not modifying. You can't actually 'modify' the name or anything.

but with things such as step...

Since they're global procs, and there's no type to override them under. The same applies for your own global procs.

.> not hard to put it after each call, but would save on file space per each :)

File space isn't what's of concern at all.
Note that you can always use a wrapper proc for a built-in instruction or replace it in code using a #define.
proc/mystep(atom/a,b,c)
   step(a,b,c)
   a.icon_state = "x"
//or
#define step(a,b,c) step(a,b,c);a.icon_state = "x"
Dec 31 2009, 5:24 pm
In response to Forum_account
Forum_account wrote:
In a game with dozens of object types and hundreds of procs, you might remember that the command to make a mob attack is mob.attack() and the command to make a mob run away is mob.run_away(). But will you remember that the command to make a mob block an attack is called mob.blocK() or mob._block()? Probably not.

Conventional naming says you'd name your procs _attack(), _run_away() and _block() to keep that kind of confusion from happening.
Dec 31 2009, 10:04 pm
In response to Tiberath
Just use a synonym, guard(), done.
Dec 31 2009, 10:39 pm
In response to Vermolius
Vermolius wrote:
Just use a synonym, guard(), done.

Mine would probably be attack(), flee() and defend() if the truth be told. And I'd probably throw them in a datum (probably named "combat").
Jan 1 2010, 4:26 am
In response to Tiberath
Tiberath wrote:
Conventional naming says you'd name your procs _attack(), _run_away() and _block() to keep that kind of confusion from happening.

That's a convention that few programmers use.

If your first programming experience was with DM you'll be comfortable with these quirks. Issues like this don't affect you, but it doesn't make DM very inviting to programmers with previous experience with other languages. Experienced programmers would, in theory, make better games than people with no experience. In the interest of bettering the BYOND community, you shouldn't be so quick to dismiss these issues.
Jan 1 2010, 4:29 am
In response to Nadrew
Nadrew wrote:
From what I've heard of the code behind the compiler, this would be far more work than it would ever be worth.

I had a hunch this was the case. There are some other code snippets I've found that you would expect to be handled properly, but aren't.
Jan 1 2010, 4:45 am
In response to Forum_account
Forum_account wrote:
That's a convention that few programmers use.

If the person is a programmer, chances are they use conventional naming in some aspect. It's considered bad practice to not use it... Otherwise, islist(L) might as well be kitten(L).

If your first programming experience was with DM you'll be comfortable with these quirks. Issues like this don't affect you, but it doesn't make DM very inviting to programmers with previous experience with other languages.

Every language has little things like this that bug programmers. I find that's the case with Python defining functions with "def function_name():" instead of PHPs "function function_name()" or DMs "proc/function_name()". These are incredibly small hurdles programmers learn to get over quickly.

Experienced programmers would, in theory, make better games than people with no experience.

That theory is flawed. They'd make better programmed games, that doesn't necessarily constitute better games. The lesser programmer might go the round about way of doing things, but if the game is fun, it's still better than the best programmed boring game in existence. Because no one cares how well a game performs, they care how much fun it is.

In the interest of bettering the BYOND community, you shouldn't be so quick to dismiss these issues.

I dismiss them because I work around them with methods so easy that it doesn't actually bother me at all. If I come across a reserved word, I pick another that's just as easy to remember.