ID:1251599
 
So I've been working with C++ for a while now, and one functionality is that you can use classes as variables within other classes, which I found to be remarkably useful. This peaked my interest on whether or not DM was capable of the same function...

mob/player
var
mob/other
verb/test()
src.other.loc = locate(src.loc)

... and to my complete surprise I found that it was.

I've been wasting so much of my life making arrays of variables and weird containers, but now that I know I can just build a variable container object, it is likely to make my life so much easier.

How did I completely miss this? And do others use this functionality a lot?
I didn't know about it until a few month ago but it is probably one of the main features I use. lol
Wait, how did you interact with objects before?

Also, locate(loc) isn't valid syntax. The loc var itself contains an /atom and is defined as one.

...So yes, it's used a lot.
What do you mean? The normal method of interacting with objects. Calling functions and altering variables, but I hadn't actually starting storing objects IN others as variables until recently.
In response to Solomn Architect
You can't access an object without a variable pointing to it, is what I'm getting at. You just didn't know you could make your own typed variables?
I was just using loc as an example, but that's interesting, I didn't know that it was an object itself.

EDIT: Essentially, yes. But I do know that you need a pointer variable to access another object's vars and functions.
In response to Solomn Architect
Yeah. The compiler gives you errors when you try to access properties (vars/procs) of a variable of a type that doesn't have those properties. The only reason to define variables with a type is to get these errors when you mess up.

e.g.
var turf/t = ...
world << t.client
// That would give a compile-time error
// because turfs don't have the client variable


Then there's the colon operator for lazy people who want their code to be bad.
var t = ...
world << t:client
// It will give a runtime error if t is set to
// something that doesn't have a client var


Also, some fun.
mob.client.mob.client.mob.client...
I just wish it worked for list values.
I know that, the model I was talking about was:

object1
var/var1
object2
var
var1
object1
proc/getSomething()
return src.object1.var1

^ Like that. Object2 being able to hold a member of object1 and utilize it's variables. I'd probably actually make it more useful for contents and array management. Giving the manager object all of the variables and procs needed to handle the data. Of course it can be used for so much more, that's just one practical application.
You're all failing to actually initialize the variables or set them to anything, every single one of these examples will generate a 'cannot read null.variable' runtime error :)
In response to Nadrew
You actually have a very valid point. Although the fix for that is just using new/object. :P
In response to Solomn Architect
var object1/object1 = new
I have a habit of completely defining objects.
var/object/object1/o = new/object/object1
In response to Murrawhip
Unfortunately lists have this problem of giving no indication of contained types at compile-time. How could it? It would probably need to run escape analysis on the list, run analysis on assignments etc and still only be able to permit this at compile-time in some cases, sadly. Other dynamic languages do this via runtime/late binding, which is basically what the : operator is about in DM.
This is a really useful part of DM, it makes things a lot easier for you (especially in terms of debugging)

I use this kind of thing in a lot of places, one example being in the Body Parts system I use.

obj
BodyParts
var
tmp/mob/Owner

proc
apply_owner()
for()
if(loc)
Owner = loc
return
sleep(10)

New()
..()
spawn() apply_owner()


The Owner variable being the focus here, I always specifically type references.
This is one of the most common uses of variables. Games on BYOND frequently have things such as "equip" items (weapon, armor, etc), many data-types need to reference a "parent," and often it's useful for objects to track an "owner." You'll find plentiful references to this usage in the DM language reference material. i.e.:

http://www.byond.com/docs/guide/chap05.html#5.2.2.1
http://www.byond.com/docs/guide/chap18.html

http://www.byond.com/docs/ref/info.html#/var
http://www.byond.com/docs/ref/info.html#/datum/proc/New

I encourage you to read through them sometime; you may learn a little more as well!