Simple Question

ID:157919
 
Dec 7 2009, 10:19 am
I think this is a basic concept in coding but I'm kinda new to coding so forgive me for my ignorance but what does the ..() line of coding mean? Like what does it do exactly? I've been reading the DM guide and I always seem to get confused when the ..() is used.
Dec 7 2009, 10:23 am
When you don't know what something does, you refer to the resources, such as the Dream Makers guild, the DM Guide, and the DM Reference, rather than asking about it in the forums.
If all else fails, then before you post, you use the forum search to find previous threads where your question was answered already.
Dec 7 2009, 10:34 am
In response to Kaioken
Alright will do
Dec 7 2009, 10:43 am (Edited on Dec 7 2009, 11:23 am)
Here's where it is in the reference, but there's a few things it doesn't explain well.

Lets say you've got code that looks like this:

mob
    monster
        
        var/hitpoints
        
        New()
            if (hitpoints == null)
                hitpoints = 1
            ..() // Keep on going up to /mob

        kobold
        
        snake
        
        unicorn
            name = "unicorn"
            desc = "I'm a unicorn!"
            
            New(var/loc)
                view() << "A [name] appears in a flash of light!"
                ..() // Head on down to mob/monster.New() now.


The first thing you have to know is what a parent and child is. The kobold, snake, and unicorn's parent is mob/monster, in other words they are children of mob/monster, because that is where they are defined. For the same reason, mob/monster's parent is mob, and one of mob's children is monster.

What the ..() does is execute the same name proc if it exists in the parent proc. If you omitted New(), this is done automatically, as though the default New() already contains a ..(). However, once you've added New(), I've noticed that the parent's version of New() does not execute unless you include ..().

Consequently, because I've made it so the unicorn announces its presense, its hitpoints would not be set to 1 if null unless I put that ..() in its New() proc, but the other mobs will call that New() proc anyway.

Because ..() is basically just executing a parent's proc, you can also use it to return a return value in that proc by typing return(..()) You can also put arguments in there.

Note, if you're overriding procs that you created, you only define proc/ on the highest parent level, otherwise you'll get a compile error that you're trying to redefine the proc. Predefined procs don't have this problem because you never use proc/ to create them anyway.

That I'm aware of, BYOND does not have reverse inheritance. You can access a parent's proc from the child, but not the other way around. (It's for the best, really, reverse inheritance is tricky business.)
Dec 7 2009, 10:47 am
In response to GospelEX
Honestly.. Guy who posted "Read the guide"... Why post anything at all if your just going to not answer the question, Your just wasting space stop being an ass. By the way..

..()


Basically will allow somthing to contine. like. lets say an object is told to do somthing when its created
obj/New()
    src.name="Im an object"


Then later on you make another object and want that to do somthing as well when its created
obj/ObjectOfDeath
    New()
        src.KillEveryone()

Bascially what will happen is the first New or the most relavant will be called but the other wont since it will kill the proccess after it finishes. Too Make it coninue to all other proccess containing or pertaining to the same thig youd do this ..()
obj/ObjectOfDeath
    New()
        ..()  // This call its first New the name one. then do the rest
        src.KillEveryone()







Welcome to Byond and happy learning! :).


*My answer may not be exact and may do other things. But that is the simplest and most coomon thing it is used for! :P*





EDIT: AH! some one beat me to it! lol
Dec 7 2009, 10:53 am
In response to Bladeshifter
Blade, please try to be as literate as possible.
Things like contine can confuse people.
I would recommend using Mozilla Firefox with it's built in Spell Checker.
But other than that, Kaioken was being smart in his post.
Instead of telling the answer, tell them how to get the answer, this way they at least learn How-To along the way.
Dec 7 2009, 11:02 am
In response to Geldonyetich
Geldonyetich wrote:
Note, you can only nest procs like this for predefined procs like New().

Procedure overriding works exactly the same with both custom and built-in procs.
Dec 7 2009, 11:04 am (Edited on Dec 7 2009, 11:26 am)
In response to Kaioken
Kaioken wrote:
Geldonyetich wrote:
Note, you can only nest procs like this for predefined procs like New().

Procedure overriding works exactly the same with both custom and built-in procs.

I suppose it would, if it didn't generate an error about redefining a pre-existing custom proc on compile, preventing the creation of any procs that could inherit this way.

batch_Beautification.dm:175:error: BeautifyWall: duplicate definition
batch_Beautification.dm:153:error: BeautifyWall: previous definition

error from:

obj/beautify

    proc/BeautifyWall()
        // Code goes here.
    universe
        proc/BeautifyWall()
            ..() // So, how would this work, then?

In this way, only predefined proc types can be overridden. Though I have done code workarounds for both this kind of inheritance and reverse inheritance.

[edit: Actually, I just learned something today, apparently you can nest your own custom procs if you only put proc on the most parent level you want your own custom proc to exist on]

// This compiles fine.
obj/beautify

    proc/BeautifyWall()
        // Code goes here.
    universe
        BeautifyWall() // No proc/ here!
            ..() // This is how it would work.

Ah, so much time wasted on overriding a limitation that wasn't there. The bad habits we pick up in isolation.
Dec 7 2009, 11:33 am
In response to Geldonyetich
Oh I see...I believe I have a better understanding now(time to play around with it now), thank you and thanks to others who posted offering help.
Dec 7 2009, 12:06 pm
In response to Geldonyetich
It took me a minute to see what you were having trouble with but I see it now.

The trick is the proc keyword. That keyword indicates to the compiler that a new proc is being defined. If you have already defined the proc at a higher level (or even the same level), you can override it, but the override doesn't use the proc keyword. The same thing applies to verbs.

When you used the keyword a second time for the same proc, the compiler thought you were trying to redefine the proc when one already existed in that inheritance tree.

Lummox JR
Dec 7 2009, 12:58 pm (Edited on Dec 8 2009, 5:07 am)
In response to Lummox JR
It's an assumption I built because, in other programming languages/compilers I've used, such as Java, there's no "proc" keyword per se so much as functions are identified by syntax, and one might get so used to identifying functions by their access designators (e.g. "public static void") that they come to believe there's no function without. I might have even used some programming languages where there is such a keyword, but you always use it - I think Visual Basic is like that? In all cases, there's not question of when you can or cannot use the keyword preceding a function, there either is no such keyword or there's one you always use.

Thus, I just assumed proc/ would be there for any custom function wherever I defined it because that was the apparent BYOND syntax. When it caused an error, it seemed to me as though I was simply being told I couldn't define custom functions of the same name in children (why not - this being an interpreted language and whatnot).

I gained a bit of new understanding today in realizing that proc/ in BYOND is handled in much the same way as var/ is. Though it's weird in that it introduces a new element of proximal keyword consistency, it makes good sense because it prevents itself from being redefined so as to avoid the usual scope difficulties that would plague new programmers. (E.G. if I declared the same variable in JAVA in a child and in a parent, I would end up with two variables of the same name, but you always have to include the parent path to specifically access the parent's variable anyway - BYOND does not force you to use the path to access a parent's variable, and avoids the conflict because it doesn't allow two variables of the same name to exist across parent to children.) That verb/ is handled the same way is good to know.