ID:268306
 
Sadly I've been coding on byond for a long time and I still don't quite fully understand ..() and using return..()

from what I read in the reference and guide ..() returns a value to the parent proc, which is default null unless changed, so why would you put ..() in if all it does is return null?

what the heck does return..() do? I heard that it tells the proc to keep on doing what it normally does, and I've heard various other things also... but no one I've talked to knows very well what it does.

I've tried using/playing around with these, and I've come to no apparant grasping of their concept.

Let me give some examples and then maybe someone can explain what it is doing in their situations, so that I can play and toy with them from there...

mob/New()
..()
t=3
return..()

why is it that some people put ..() right at the beginning of the coding tree? What exactly does this do? From what I understand isn't ..() null, in which case wouldn't it stop the procedure from continueing because return from what I gather if not specified anything defaults to . which is null and I know return (also return 0) stops procedures from doing what they need to like Del() deleting a mob or New() doing it's default stuff.

What is return..() doing exactly? From what I gather from the reference and guide puting these 2 together is exactly the same as plain . which is null.

regarding return....

return 0 = null which means stop calling parent proc
return 1 = keep calling parent proc...
return..() = (trying to get answered)
is there any other possibly additions to return that I am unaware of or can be used?
world
New()
..()
world << "world is made"

world
New()
world << "world being made"
..()


If u ask me ..() makes sure build-in code is executed.
But you can also make use of it urself.
For example if you have obj's representing skills.

obj
proc
use()
world << "Using a skill"
..()
fire_ball
use()
world << "You shot a fireball! :O" //whatever teh skill will do
ice_bolt
use()
world << "Brrrrr cold here!" //whatever

Now you could use stuff like:
var/list/l = new/list()
for(var/obj/skill/s in usr.skills)
l.Add(s)
var/obj/skill/S = input("Sellect ur skill") in l
S.use()


Now this will display "Using a skill" and then depending on what skill chooce "Brrrrr cold here!"
If i didnt put .() in the first proc you would only see "Using a skill" displayed and then the proc would stop.

Hope u'll get it =P I'm so bad in explaning

Greetz Fint

Jon Snow wrote:
Sadly I've been coding on byond for a long time and I still don't quite fully understand ..() and using return..()

from what I read in the reference and guide ..() returns a value to the parent proc, which is default null unless changed, so why would you put ..() in if all it does is return null?

..() by default only calls the parent proc... It simply is a command that says "execute the code in the parent version of the current proc"...

However, you can also think of it like any other proc call... It has parentheses on the end to pass arguments back... For instance, you could do ..(M) if you wanted to pass the var "M" back to the parent... It's like a short way of saying: "CallThisProcsParent()"...lol

And why do we use it? Simple: If you override a proc, then whenever you call that proc from within the child type, then it won't execute the code in the parent's version... This is especially bad if you override New(), because without adding ..(), then none of the built-in functionality for New() would be executed... Basically, the object won't be created, since New() does most of that stuff...lol

Here's an example:

mob
proc
SomeProc(mob/M)
src << "Thanks for calling me, son!"
if(M)
src << "Wow, my caller ID told me that it was [M] calling!"
badchild
SomeProc()
src << "I'm bad, and I won't call my parent..."
goodchild
SomeProc()
src << "I'm going to call my parent..."
..()
psychicschild
SomeProc()
..()
src << "How'd you know I was calling you?"
callerIDed
SomeProc()
src << "I'm calling my parent..."
..(src)

Now, if you call SomeProc() from /mob, then all you get is:
"Thanks for calling me, son!"

If you call it from /mob/badchild, then you get:
"I'm bad, and I won't call my parent..."

But if you call it from /mob/goodchild, then you get:
"I'm going to call my parent...
Thanks for calling me, son!"

If you call it from /mob/pyschicschild, then you get:
"Thanks for calling me, son!
How'd you know I was calling you?"

And finally, if called from /mob/calledIDed, then you get:
"I'm calling my parent...
Thanks for calling me, son!
Wow, my caller ID told me that it was callerIDed calling!"

See? At whatever point you add it to a child proc, it basically inserts the parent proc's code, passing along any optional arguments you stick in...

what the heck does return..() do? I heard that it tells the proc to keep on doing what it normally does, and I've heard various other things also... but no one I've talked to knows very well what it does.

First off, you've got to understand what "return" does (you might already, but just to be safe)... return does exactly that, it returns something... It sends what follows it back to whatever proc called the current proc (along with ending the current proc)... If nothing is added after "return", then a null value is sent back to the calling proc... However, if something is added after return (like "return 3"), then that something is passed back to the calling proc...

Now, using "return ..()" returns whatever value the parent proc returns... This line is basically playing the "middleman"... It grabs whatever value the parent proc sends, and then sends it to the calling proc...

So for another example:

mob
SomeProc()
return "I'm sending this text string back..."
child
SomeProc()
return ..()
proc
SomeOtherProc()
src << "[SomeProc()]"

Now, if you call mob/child/proc/SomeOtherProc(), then you get:

"I'm sending this text string back..."

Because SomeOtherProc() outputs a text string given to it by child's SomeProc()... That proc has a "return ..()" line so it then calls it's parent, which returns that message, and in turn, returns that...

I've tried using/playing around with these, and I've come to no apparant grasping of their concept.

Let me give some examples and then maybe someone can explain what it is doing in their situations, so that I can play and toy with them from there...

mob/New()
..()
t=3
return..()

why is it that some people put ..() right at the beginning of the coding tree? What exactly does this do? From what I understand isn't ..() null, in which case wouldn't it stop the procedure from continueing because return from what I gather if not specified anything defaults to . which is null and I know return (also return 0) stops procedures from doing what they need to like Del() deleting a mob or New() doing it's default stuff.

What is return..() doing exactly? From what I gather from the reference and guide puting these 2 together is exactly the same as plain . which is null.

regarding return....

return 0 = null which means stop calling parent proc
return 1 = keep calling parent proc...
return..() = (trying to get answered)
is there any other possibly additions to return that I am unaware of or can be used?

(More later, I'm out of time... Unless someone else wants to take over...)
In response to SuperSaiyanGokuX
SuperSaiyanGokuX wrote:
And why do we use it? Simple: If you override a proc, then whenever you call that proc from within the child type, then it won't execute the code in the parent's version... This is especially bad if you override New(), because without adding ..(), then none of the built-in functionality for New() would be executed... Basically, the object won't be created, since New() does most of that stuff...lol

Actually New() is called after BYOND has created an object. It doesn't have any default behaviour.
Jon Snow wrote:
Sadly I've been coding on byond for a long time and I still don't quite fully understand ..() and using return..()

from what I read in the reference and guide ..() returns a value to the parent proc, which is default null unless changed, so why would you put ..() in if all it does is return null?

What ..() does is calls the code in the parent procedure.
For example, say you have a /mob and a /mob/player:
mob
New()
world << "Mob [src] has been created!"

mob
player
New()
src.loc = locate(1,1,1)
..()

When a /mob/player is created, it will first be moved to 1,1,1 like its New() proc states. Then the parent procedure (/mob/New()) will be executed, and that line outputting to world will be run.

what the heck does return..() do? I heard that it tells the proc to keep on doing what it normally does, and I've heard various other things also... but no one I've talked to knows very well what it does.

return sets the return value of the procedure, and ends the procedure. Example:
proc/IsNumberLessThanTen(number)
if(number < 10)
return 1 // 1 is usually used as "true"
else
return 0 // 0 is usually used as "false"

mob/verb/test(number as num)
if(IsNumberLessThanTen(number))
src << "The number is less than 10!"
if(!IsNumberLessThanTen(number))
src << "The number is not less than 10!"


If ..() is called in a procedure, the parent proc's code is called, and nothing more. If return ..() is called, then the current proc will call the parent's code as well as return the value the parent proc returns. It's useful in situations like when overriding Enter() if you want to make a modification to Enter(), but also have it act as it normally would in certain cases.

..() is sometimes overused since people don't always know what it's for, and including it seldom does harm. In the reference, if an overridable proc(eg Move()) has a default action, ..() will cause that default action to occur.
In response to SuperSaiyanGokuX
that was a ton of help I understand now!! One more question though...


Ok when you have -

mob/New()
world<<"Hey!"

in codefile abc

and

mob/New()
world<<"hey..."

in codefile cba

what's the order of operations? Would you use ..() to call the 2nd edit to New()?

and does it matter if you have return at the end of a proc to stop it since it should just stop on it's own and return is unecessary?

like

mob/proc/Example()
world<"example"
return
In response to Fint
Except for the fact that you would want to put ..() in both the child procs, not in the parent proc.
In response to Jon Snow
Procs will return null by default, so you don't have to use return at the end of every proc you make.
In response to Loduwijk
omg I figured out what I was doing wrong I think... you don't need to call the parent proc for stat() because it doesn't do anything in order to have it keep getting called... lol I didn't realize that :P
In response to Jon Snow
client/Stat has a default action (It calls mob/Stat), but mob/Stat does not.
In response to Loduwijk
oh crap well if there isn't a client then there's no reason to call stat then I guess... so my changes don't need fixing :P