Up to Main Index                               Up to Journal for May, 2012

                      JOURNAL FOR FRIDAY 11TH MAY, 2012
______________________________________________________________________________

SUBJECT: If an apple is of type food is it also edible?
   DATE: Fri May 11 20:06:05 BST 2012

At the moment I'm having a right pickle of a time trying to sort the basic
structure of WolfMUD. Currently for the prototype everything is in one
package. Not a good idea for the long term.

For my first attempt I tried creating separate packages for types of things
but ended up with a complex circular import situation  between packages :(

I think my main problem is that I'm not thinking Go-ish enough and thinking
more OOP instead.

So back to the Go reference materials for some reading. For interfaces it says
they 'specify the behaviour of an object'[1]. OK got that. The other piece of
the puzzle - I think - is embedding[2].

So if I define behaviours based on commands a thing can understand, violating
the 'er' for one method interface naming for now:


  type Examinable interface { Examine() }
  type Edible     interface { Eat()     }
  type Gettable   interface { Get()     }


We could compose a food interface type by embedding the interfaces:


  type Food interface {
    Examinable
    Edible
    Gettable
  }


Now if for each interface we have a struct with receiver methods we can
compose a default food type using:


  type food struct {
    examinable
    edible
    gettable
  }


So food should be able to do everything examinable, edible and gettable can
do. Resulting in something like:


  > get apple
  You get the apple.
  > examine apple
  You examine an apple. It's a fine juicy apple and not a maggot in sight!
  > eat apple
  You eat the apple.
  >


Using these basics creating poisoned food could be done using:


  type poisonedFood struct {
    examinable
    gettable
  }

  func (pf *poisonedFood) Eat() {
    poisonPlayer()
  }


Just add our own implementation of eat() to handle the fact it's poisoned and
satisfy the Edible interface. Voilà! We can now use poisonedFood anywhere we
can use food - well the Edible interface type really ... I think?

Well that's the theory anyway. As they say - The Devil is in the details  >:)

For instance in this simple example how do we know who/what is eating? Who can
observe who/what that is doing the eating? How do we tell the edible we want
to eat it? Can who/what actually eat anything? That's where a beautifully
simple idea breaks down into chaotic complexity.

Now where did I put my drawing board? Ah there it is ...


  Diddymus sighs.
  You see Diddymus go back to his drawing board.
  >


--
Diddymus

  [1] https://golang.org/doc/effective_go.html#interfaces_and_types
  [2] https://golang.org/doc/effective_go.html#embedding


  Up to Main Index                               Up to Journal for May, 2012