How did I completely miss this?

ID:1251599
 
Apr 30 2013, 9:51 am
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?
Apr 30 2013, 9:54 am
I didn't know about it until a few month ago but it is probably one of the main features I use. lol
Apr 30 2013, 10:18 am
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.
Apr 30 2013, 10:22 am
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.
Apr 30 2013, 10:23 am
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?
Apr 30 2013, 10:26 am
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.
Apr 30 2013, 10:36 am
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...
Apr 30 2013, 10:52 am
I just wish it worked for list values.
Apr 30 2013, 11:03 am
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.
Apr 30 2013, 11:16 am
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 :)
Apr 30 2013, 11:24 am
In response to Nadrew
You actually have a very valid point. Although the fix for that is just using new/object. :P
Apr 30 2013, 11:25 am
In response to Solomn Architect
 
var object1/object1 = new
Apr 30 2013, 11:28 am
I have a habit of completely defining objects.
var/object/object1/o = new/object/object1
Apr 30 2013, 11:36 pm
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.
May 1 2013, 1:00 am
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.
May 2 2013, 6:56 am
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!