# BYOND Inheritance

## `..()`

Here's our base example of inheriting and adding on functionality to a proc.

// base type of this example
/obj/item/ball
  name = "ball"

//proc fired when a ball is created
/obj/item/ball/New()
  throw_ball()

//proc to "throw" itself, i guess
/obj/item/ball/proc/throw_ball()
  //imagine some functionality that moves the ball here, or something.
  //for sake of example, I just make it move one tile in whatever dir it faces.
  Move(get_step(src, dir), dir)

// a subtype that has messages
/obj/item/ball/verbose
  name = "verbose ball"

/obj/item/ball/verbose/throw_ball()
  // When we want to throw the ball, we send a message
  world << "Verbose ball thrown."

This code will not work.
There's an error! When the verbose ball is created, it will print the message to world but it won't run the parent proc's code. We can fix that by doing this:

/obj/item/ball/verbose/throw_ball()
  // call the parent proc, running line 11 on the previous example
  ..()
  // When we want to throw the ball, we send a message
  world << "Verbose ball thrown."

This fixes the issue. Procs override procs, so when you declare what a child proc will do (verbose's throw_ball) it overrides what it would do (/obj/item/ball's throw_ball). But when we still want to do what the parent did, we call ..()

## `. = ..()`

Code sometimes relies on a return value from another proc! Let's quickly set the scene

/mob/living
  //the living type defines health, so all subtypes have health
  var/health = 10

// for the sake of example, pretend this proc goes off when moving
// (and it was defined on /mob/, behavior inherited by /living)
/mob/living/on_move()
  //check if the mouse can move
  if(can_move())
    //go ahead and do the move behavior on /mob
    ..()
  //otherwise we're doing nothing

// movement checking proc, let's say we don't want living things to move if dead.
/mob/living/proc/can_move()
  //we return false if health is 0, 1 otherwise.
  return health

This code will work!
Looks good. Now let's make a mouse subtype that can get trapped.

/mob/living/mouse
  //if trapped, we shouldn't be able to move
  var/trapped = 0

/mob/living/mouse/proc/can_move()
  ..()
  // return a flipped value so 0 returns 1 (not trapped, can run) and vice versa
  return !trapped

Now we've run into another bug.
This code only partially works. It listens and behaves correctly to being trapped, but it has somehow forgotten that dead living things don't move. This is because the parent proc is called, but the result of it (0 if there's no health) is not stored in a variable or considered.
Take a look at this fix:

/mob/living/mouse/proc/can_move()
  // the parent proc returns a boolean true or false
  // based on being alive for movement.
  // ..() gets the return value, let's not lose it this time and set it as a variable!
  var/is_alive = ..()
  // now return a flipped value so 0 returns 1 (not trapped, can run) and vice versa
  return !trapped && !is_alive

Now it will work. But we can do one better. Time to try out the dot variable! Not the dot operator, which is used to access variables on an instance, but the variable that is inherent in each proc!

/mob/living/mouse/proc/can_move()
  //we don't have to declare . because it is already in each proc.
  //. is, essentially, what the proc will return BY DEFAULT.
  . = ..()
  if(trapped)
    return 0
  // in the case trapped is not true, instead of returning null it returns .
  // . is set as what the parent proc returned!
  // (and that's our health check!)

Now it works without unnecessary verboseness!
If you're going to capture a return value to just return it, it might as well be .
There's other tricks with . and a whole lot of debate about correct and incorrect uses (. can be a readability problem) but don't worry about that for now.

## Summary

* `..()` calls the parent proc src proc inherited from.
* `.` variable is the default return value of a proc, usually null
* `. = ..()` calls the parent proc and makes the default return value what the parent returned