Differences.

ID:158188
 
Oct 14 2009, 9:25 am
What is the difference between the following?:

mob
    Move()
        var/x = ..()
        if(x)
            world<<"woot"
        else
            world<<"aw."



mob
    Move()
        . = ..()
        if(.)
            world<<"woot"
        else
            world<<"aw"





Another question,

Oct 14 2009, 9:34 am
Speedro wrote:
What is the difference between the following?:

mob
>   Move()
>       var/x = ..()
>       if(x)
>           world<<"woot"
>       else
>           world<<"aw."


mob
>   Move()
>       . = ..()
>       if(.)
>           world<<"woot"
>       else
>           world<<"aw"

Another question,


In the second one, ..()'s return value will be returned...
Oct 14 2009, 9:47 am
The difference is that, in one, there is a period at the end of "aw", and, in the other, there is no period at the end of it. ;)

Really, the main difference is that the first one breaks Move() in that anything which relies on Move()'s returning the success/failure condition of the movement will always think Move() failed with the first one.

All functions have a built in variable called "." All functions which do not encounter a "return" statement and instead reach the end of the function without being told to return, they will return "." This built in variable defaults to null.

So, behind the scenes, there are several implied lines of code. Think of it this way: the first line of any and all functions is always "var/. = null" and the last line of all functions is always "return ." You don't see them, but they are always there.

If you then return something yourself before it encounters the "magic return" then it will return what you tell it to return and abort as normal, so having "return ." as the last line doesn't get in the way of you returning what you want.

Since there is an implied "." variable for all functions, in any function you can change it to whatever you want, which then changes the default return value, that is, what the function will return if it gets to the end without encountering any other return statement.
proc/myFunction()
    switch(rand(1,4))
        if(1)
            return // return without any value returns null by default
        if(2)
            return 1
        if(3)
            . = "hi"
    if(prob(50))
        return new /obj
    else if(prob(50))
        return .

In the above example, the initial switch makes it so that there is a 1 in 4 chance the function will return null, 1 in 4 it will return 1, and 1 in 4 chance that it will not return anything yet and continue on with the function, but even if it does continue on, it has ". = "hi"" so it sets up the default return value.

When it continues (if it continues, wasn't returned from before on a 1 or 2), there is a 50% probability that it will return a new /obj and a 25% probability (only 1 in 2 it even gets past the previous if, and a 1 in 2 times 1 in 2 gives 25%) that it will be told to return whatever the default return value is (if rand() gave a 4 before, this will be null, if a 3, it will be "hi").

If it gets past the last "else if" part, I didn't tell it to return anything at the end, so it will "return ." by default anyway, making the else-if part I wrote redundant (useless), and it will then return either null (on rand() of 4) or "hi" (on 3) anyway.

In the end, there is a 37.5% chance it will return null, 25% chance that the function will return 1, 25% it will return a new /obj, 12.5% it will return "hi".

I hope that example makes sense and gives a clearer idea of how the different scenarios work out.
Oct 14 2009, 12:19 pm
In response to Loduwijk
Ah thanks for your time :)
Oct 15 2009, 1:17 pm
In response to Loduwijk
 

> proc/myFunction()
>     switch(rand(1,4))
>         if(1)
>             return // return without any value returns null by default
>         if(2)
>             return 1
>         if(3)
>             . = "hi"
>     if(prob(50))
>         return new /obj
>     else if(prob(50))
>         return .
>


Actually why do you need to return "." at the end, if that's now the default return value anyways?

So basically setting . just sets the default return value unless otherwise stated?

Then why use . = ..(), when that would be the return value anyways, besides storing the value for use later?
Oct 15 2009, 1:23 pm
In response to Speedro
Speedro wrote:
Actually why do you need to return "." at the end, if that's now the default return value anyways?

You don't. However, it's generally clearer.

So basically setting . just sets the default return value unless otherwise stated?

Yes.

Then why use . = ..(), when that would be the return value anyways, besides storing the value for use later?

Because .=..() is what sets the return value for later. It's like asking "why go to the park if you'll go to the park anyway?"

Also: in the case where an object's procs are ended prematurely due to its deletion, . serves the purpose of allowing those procs to still return a value even if they are interrupted. A bit obscure, but situationally useful.
Oct 15 2009, 2:31 pm
In response to Garthor
If you felt up to the challenge, could you provide a simple example of when this would be neccessary? Just so I'm sure :)
Oct 15 2009, 2:39 pm
In response to Speedro
Oct 15 2009, 3:56 pm
In response to Garthor
Haha I'm already using that library in my project. Thanks again for making it available, saved me a lot of time.
Oct 16 2009, 1:03 pm
In response to Speedro
Speedro wrote:
Actually why do you need to return "." at the end, if that's now the default return value anyways?

You don't, and I mentioned that in part of my explanation of that code. I said that the "return ." line at the end is redundant, and I even said after that, in parenthesis, that it was useless. It was just part of the example.