ID:138141
 
I have no idea whether it's possible or not, but it would remove a whole classification of bugs if the usr object knew its type.

It is rather unintuitive to call a system-provided object that doesn't know its type.

In other words, people calling usr.my_var for a var assigned to /mob/player should work.
On 3/6/01 9:47 pm Deadron wrote:
I have no idea whether it's possible or not, but it would remove a whole classification of bugs if the usr object knew its type.

It is rather unintuitive to call a system-provided object that doesn't know its type.

In other words, people calling usr.my_var for a var assigned to /mob/player should work.

The problem is that these are compile-time errors, and the value of usr is determined at runtime. I suppose that for the common case of mob verbs, the compiler could _assume_ that usr is the same type as src, eg:

mob/player1
var/test_var
verb/test_verb()
usr.test_var = 1

But I think it's better style to just use 'src' in these cases anyway. For almost all mob verbs, usr == src, but src has the advantage of being typed.

Theoretically, usr could be the "wrong" type, even in the above case, eg:

mob/player2
verb/call_by_proxy()
mob/player1/M = locate() // find us a player1
M.test_verb() // oh no, run-time error inside test_verb, since it assumes usr is a player2

For non-mob verbs, I don't see how the compiler can know what type usr is. So it assumes the most general case, that usr is a mob.

In response to Tom H.
The problem is that [snip]

Yeah, I was thinking of requesting the very same thing a few weeks ago, but then realised the case you just presented, and scratched the idea. However, a thought just dawned on me... Perhaps a workaround would be to first check world.mob to see if the variable is in that type, then to check /mob to see if the variable is in that type?
In response to Spuzzum
Yeah, I was thinking of requesting the very same thing a few weeks ago, but then realised the case you just presented, and scratched the idea. However, a thought just dawned on me... Perhaps a workaround would be to first check world.mob to see if the variable is in that type, then to check /mob to see if the variable is in that type?

You kids and your newfangled ideas! A wise man once told me not to use "usr" any more than I have to. Well, I usually disregard that suggestion, but it's still good advice. The best thing to do, if you write a verb that assumes usr is a certain type of object, is state it explicitly in the verb:

verb/bla()
var/mob/player/dwarf/Valley_Dwarf/D = usr
if(istype(D)) D.valleyPower++

Which, of course, you know. But I had to speak up, because I believe: if it ain't broke, don't fix it! :)
In response to Guy T.
On 3/7/01 3:10 pm Guy T. wrote:
You kids and your newfangled ideas! A wise man once told me not to use "usr" any more than I have to. Well, I usually disregard that suggestion, but it's still good advice. The best thing to do, if you write a verb that assumes usr is a certain type of object, is state it explicitly in the verb:

verb/bla()
var/mob/player/dwarf/Valley_Dwarf/D = usr
if(istype(D)) D.valleyPower++

Which, of course, you know. But I had to speak up, because I believe: if it ain't broke, don't fix it! :)

And the wise man never uses usr if at all possible...BUT I would claim it is broke, cause almost every new BYOND programmer gets mysterious bugs due to this.

Now maybe in the future those people will read the faq and it won't be an issue...
In response to Deadron
On 3/7/01 3:50 pm Deadron wrote:

And the wise man never uses usr if at all possible...BUT I would claim it is broke, cause almost every new BYOND programmer gets mysterious bugs due to this.

But when you say "broke", what do you mean? I may be missing the point, but aside from the hack I mentioned in a previous post I can't think of any way usr could be expected to work if it were given type information. Can you give me an example of a proc that could benefit from all of this but not potentially crash at run time?
In response to Tom H.
On 3/7/01 4:17 pm Tom H. wrote:
On 3/7/01 3:50 pm Deadron wrote:

And the wise man never uses usr if at all possible...BUT I would claim it is broke, cause almost every new BYOND programmer gets mysterious bugs due to this.

But when you say "broke", what do you mean? I may be missing the point, but aside from the hack I mentioned in a previous post I can't think of any way usr could be expected to work if it were given type information. Can you give me an example of a proc that could benefit from all of this but not potentially crash at run time?

By broke I mean if you check the past month of postings, you'll find half a dozen newbies whose code broke because they assumed that usr would know it's variables. Usually this is because they have some form of /mob/player with unique variables or procs that they try to access in an object verb through usr.

In other words, it is very common to assume that using usr is like using src -- src knows what it is, so it's natural to assume that usr knows what it is.

This is all aside from the fact that there are other ways usr can surprise a newbie, such as when an NPC executes a verb that uses usr.

Anyway it's a common source of confusion.

In response to Deadron
On 3/7/01 5:53 pm Deadron wrote:

Anyway it's a common source of confusion.

Agreed! But I think it is a documentation issue, not a compiler one. Since usr can technically be any mob, the compiler cannot assume it is of a particular type, unlike src, which is well-defined. That's the difference.

Spuzz's idea of checking world.mob has some merit, though, since that will be the type for usr most of the time, I think. It's probably better to just explain this in the docs so new users will understand the situation better.
In response to Tom H.
On 3/7/01 6:13 pm Tom H. wrote:
It's probably better to just explain this in the docs so new users will understand the situation better.

New users and docs?

Oh sir your jest is a good one.
In response to Deadron
On 3/7/01 6:41 pm Deadron wrote:
On 3/7/01 6:13 pm Tom H. wrote:
It's probably better to just explain this in the docs so new users will understand the situation better.

New users and docs?

Oh sir your jest is a good one.

Too cruel... and too true. =P
In response to Spuzzum
On 3/8/01 3:26 am Spuzzum wrote:
On 3/7/01 6:41 pm Deadron wrote:
New users and docs?

Oh sir your jest is a good one.

Too cruel... and too true. =P

Hey! I'll have you know that I didn't make one post on the BYOND forum before I had a good pair of docs.

Z
In response to Zilal
On 3/8/01 11:00 am Zilal wrote:
Hey! I'll have you know that I didn't make one post on the BYOND forum before I had a good pair of docs.

Yup, you've been the model New Programmer.

If only everyone was Zilal!
In response to Deadron
On 3/8/01 2:35 pm Deadron wrote:
On 3/8/01 11:00 am Zilal wrote:
Hey! I'll have you know that I didn't make one post on the BYOND forum before I had a good pair of docs.

Yup, you've been the model New Programmer.

If only everyone was Zilal!

I've read a few docs, and had some people explain stuff to me, but i still don't get it. The documents that Dantom writes are confusing as hell! (no offense. I hope you don't take any because if you take a fence you have to put it back...)

Kevin
In response to Spastic
I've read a few docs, and had some people explain stuff to me, but i still don't get it. The documents that Dantom writes are confusing as hell! (no offense. I hope you don't take any because if you take a fence you have to put it back...)

Did you try the Dream Maker book yet? It's very well-written, if you ask me (which you didn't). Anyway, one of the great secrets of computer programming is that no matter how well-written documentation is, it's no substitute for a working example. That's why it's such a good idea to play around with downloadable programs that actually work. If you're looking at a section of code and it doesn't make sense, then the Reference often helps you understand what's going on.

Personally, I think the Forums themselves are one of the best resources you can find. Sure, probably over half the posts are not too helpful... but with a little patience you'll find a veritable gold mine of information.
On 3/6/01 9:47 pm Deadron wrote:
I have no idea whether it's possible or not, but it would remove a whole classification of bugs if the usr object knew its type.

It is rather unintuitive to call a system-provided object that doesn't know its type.

In other words, people calling usr.my_var for a var assigned to /mob/player should work.

IMHO, the programmer should be allowed to set usr to whatever default mob they wish.

In response to Deadron
And the wise man never uses usr if at all possible...BUT I would claim it is broke, cause almost every new BYOND programmer gets mysterious bugs due to this.

I suspect, however, that changing the nature of usr would not accomplish much except to defer the mysterious bugs to a later date--probably about 5 minutes later. One way or another, the programmer has to learn how the compiler handles var declarations... it seems to me that this is as good a place as any!

In retrospect it might be a nice idea to have all verbs automatically accept a first parameter equal to usr, so you'd write all verbs like so:

verb/attack(mob/usr, mob/target as mob in view(usr, 5))

...which would make the nature of usr clearer, and allow the programmer to declare a specific type right in the parameters list. But it's probably too late for that!
In response to Guy T.
On 3/9/01 7:24 am Guy T. wrote:
In retrospect it might be a nice idea to have all verbs automatically accept a first parameter equal to usr, so you'd write all verbs like so:

verb/attack(mob/usr, mob/target as mob in view(usr, 5))

...which would make the nature of usr clearer, and allow the programmer to declare a specific type right in the parameters list. But it's probably too late for that!

Now you're thinking like a wise man!
In response to Guy T.
On 3/9/01 7:24 am Guy T. wrote:
In retrospect it might be a nice idea to have all verbs automatically accept a first parameter equal to usr, so you'd write all verbs like so:

verb/attack(mob/usr, mob/target as mob in view(usr, 5))

...which would make the nature of usr clearer, and allow the programmer to declare a specific type right in the parameters list. But it's probably too late for that!

Hey, I really like that idea.

My docs comment was, of course, referring to doc martens. I don't actually have any, but I thought it would be funny. Me read docs?

Z