Double-colon accessor

ID:260703
 
Apr 7 2009, 10:37 am (Edited on Apr 7 2009, 11:15 am)
I stumbled on the usefulness of this when I looked in the object tree under /proc and saw all of my cf_ procs listed there, and thought simultaneously that requiring the datum be initialized just to use the attached procs isn't preferable. I also kept running into problems putting common functions into datums and receiving errors when trying to use them before datum/New() was finished, and also being bound to use the target datums only when they're instantiated. Given I'm not aware what manner of overhaul this might require in the frightening depths of the compiler code, just getting the idea out there for the future is good as well.

For anyone unawares, the double-colon is used to access functions and properties of objects that haven't been initialized. In terms of result, these two verbs would be identical:

mydatum
   var/special_value = 7

mob/verb/blah1()
   var/mydatum/d = new
   usr << d.special_value

mob/blah2()
   usr << mydatum::special_value
Apr 7 2009, 10:41 am
For some time now I've had a similar thing in mind which would take the more BYONDish format of initial(type, var). As I recall the last time I looked into this it wasn't as trivial as I would have liked, but that was some time ago.

Lummox JR
Apr 7 2009, 11:05 am
In response to Lummox JR
I approve, either method.
Apr 7 2009, 11:08 am
Mobius Evalon wrote:
> mydatum
>    var/special_value = 7
> 
> mob/verb/blah1()
>    var/mydatum/d = new
>    usr << d.special_value
> 
> mob/blah2()
>    usr << d::special_value
>


In that second example, how does the compiler know what "d" is? Was this a mistake, and did you really mean mydatum::special_value? If not, could you elaborate? Thanks!
Apr 7 2009, 11:16 am
In response to Airjoe
Airjoe wrote:
In that second example, how does the compiler know what "d" is? Was this a mistake, and did you really mean mydatum::special_value? If not, could you elaborate? Thanks!

Err, whoops. I did mean mydatum::special_value.
Apr 7 2009, 11:19 am
In response to Lummox JR
Lummox JR wrote:
For some time now I've had a similar thing in mind which would take the more BYONDish format of initial(type, var). As I recall the last time I looked into this it wasn't as trivial as I would have liked, but that was some time ago.

That seems good, but is there any plan for access of procs without instantiation?
Apr 7 2009, 11:22 am
In response to Mobius Evalon
Mobius Evalon wrote:
That seems good, but is there any plan for access of procs without instantiation?

Like a static proc? I don't see how that would be possible without just making it a global proc. There's no concept of /path.var anyway so /path.proc() wouldn't make sense. I'd have to have some idea of what a potential syntax would be like to say for sure, but it's likely this would be too complex to implement anyway.

Lummox JR
Apr 8 2009, 12:23 pm
Rats, I was hoping from the topic that this was something else, namely a namespace thing. Not to hijack the thread, but support for namespaces would be a nicety in the ways of avoiding library conflicts and such, or to group similar functions that don't necessarily need to belong to a datum. I'm not sure how it would fall syntactically into DM, but here were some of my initial thoughts:
namespace/something
{
   proc/init()   // something::init()
}

namespace/something/proc/init()   // something::init()

proc/init()
   set namespace = "something"

I dunno, I didn't really think extensively but rather on the spot when I read "Double-colon accessor." The former two (equivalent by BYOND's formatting schema) would probably be preferable as it makes it easier to group types and global variables into namespaces as well.
Apr 8 2009, 1:22 pm
In response to Kuraudo
That's a good idea, namespaces would make a nice addition to DM! However, if the double colon accessor Mobius suggested isn't too trivial to add, this really wouldn't be!
Apr 8 2009, 3:47 pm
In response to Kuraudo
 
#NAMESPACE NAMESPACENAME
#ENDNAMESPACE


It doesn't have to be an internal thing, it can be something the compiler handles during compile-time (conversion to unique names).
Apr 8 2009, 9:15 pm
In response to Lummox JR
I personally like the namespace idea far better, but in a general aspect both ideas are quite nifty and I could come with a million things to do with them.

I haven't seen these kind of ideas since ever.

Really good ideas guys.

Apr 11 2009, 8:24 am
Just to clarify, does the :: operator exist in BYOND yet, to access variables? I was just about to post looking for the best way to handle this sort of thing, but if the :: thing exists, it'd be really useful
Apr 11 2009, 9:33 pm
In response to Chessmaster_19
Uh, do you see a post saying it was added? Do you see it in the DM Reference? Besides, Lummox said that when/if it's implemented (which will probably take some time, mind) it will be incorporated into initial(), not a new operator. It'd be useful indeed, but for now you'll have to create a new temporary (or not) object of that type in order to read vars defined under it.
Apr 12 2009, 3:00 am
In response to Kaioken
Kaioken wrote:
Uh, do you see a post saying it was added? Do you see it in the DM Reference? Besides, Lummox said that when/if it's implemented (which will probably take some time, mind) it will be incorporated into initial(), not a new operator. It'd be useful indeed, but for now you'll have to create a new temporary (or not) object of that type in order to read vars defined under it.

Well, your original post was asking about a double colon accessor for procs, it didn't mention anything about variables, and then you gave an example (in DM) about how the double colon accessor is used. Your post was ambiguous, which is why I asked you to clarify.
And, it wouldn't be the first feature that I haven't found in the DM Reference.
Apr 12 2009, 3:38 am
Mobius Evalon wrote:
> mydatum
>    var/special_value = 7
> 
> mob/verb/blah1()
>    var/mydatum/d = new
>    usr << d.special_value
> 
> mob/blah2()
>    usr << mydatum::special_value
>


You could write it another way, using a static var, without having to initialize a /mydatum object.

mydatum
    var/static/special_value = 0
    
client/verb/Test()
    var/mydatum/d   // doesn't need to be initialized!
    src << ++d.special_value


As for static procs, they would be nice but probably not easily doable.
Apr 12 2009, 5:33 am
In response to Kuraudo
Sure, you can use and access a global var like that, but then again you don't even need an object (even defined) for a global one anyway, and on an object it can't be overridden in child subtypes and as such.