ID:170946
 
Hey, is..
var/Mail_System/M_S = new /Mail_System/

the same as..
var/Maiil_System/M_S = /Mail_System/



?
No.
Lenox wrote:
Hey, is..
> var/Mail_System/M_S = new /Mail_System/
>

the same as..
> var/Maiil_System/M_S = /Mail_System/
>

?

It's the difference between having an actual computer or having a piece of paper with the word "computer" on it.
In response to Hell Ramen
in example 1, you are creating an instance of a type. In example 2, you are referencing a type.
In response to Ter13
Ok, thank you, ^_^.
Just to elaborate on the other answers, both of those lines are in fact legal. The second one is however just a type path. If you set the var to a type path, DM won't complain, but if you go to use any vars belonging to M_S, DS will give you a runtime error because you only set it to a type path instead of a real datum.

The trailing slash in your type paths is unnecessary, but doesn't hurt anything.

Lummox JR
In response to Lummox JR
Aiight, thank you for explaining why it's like that so I know, I was sort of confused about that. EDIT: What if I go to store the instance of a Datum in a var, how would I do that?
In response to Lenox
To store an instance of a datum? You'd do this.

var/datum/D = new/datum


You could also do this:

var/D = new/datum
<dm>

But it isn't cast as a datum, meaning if you did this:

<dm>
if(D.type==/datum)


You'd get a compilation error, as DM doesn't interpret D as an instnace of a datum, it's just a normal variable.
In response to Ter13
Ter13 wrote:
To store an instance of a datum? You'd do this.

> var/datum/D = new/datum
>

You could also do this:

> var/D = new/datum
>

But it isn't cast as a datum, meaning if you did this:

> if(D.type==/datum)
>

You'd get a compilation error, as DM doesn't interpret D as an instnace of a datum, it's just a normal variable.

Aiight, Thank you.