OO Seagulls about mostly-adequate-guide HOT 3 CLOSED

You are certainly correct. It is my fault for not explaining that it is bad code on purpose. I just pushed: d51c5b5

from mostly-adequate-guide.

Please explain why 32 is incorrect and 16 is correct. In your seagull class, a flock is able to conjoin with itself and double its own size, therefor 32 is correct. A simple check for equality of flocks in the conjoin method would have prevented this unnatural behavior:

Flock.prototype.conjoin = function(other) {
  if (this === other) {
    throw('a flock cannot conjoin with itself!')
  }
  this.seagulls += other.seagulls;
  return this;
};

But I don't see a way for the functional approach to prevent self-conjoining, since the functional code is operating on number literals instead of objects. To me, this example is actually an argument against FP.

from mostly-adequate-guide.

Hi @omasback

You have a good point - if flock_a were to breed with flock_b twice, its state probably should be altered and the object would keep track for us.

The intention was to show unexpected consequences of using state and custom methods in what should be a very simple program. Well, that and show that mathematical properties can be held if we code within the "framework". I didn't realize it until just now, but it fails miserably to highlight the common problem of unintended mutation as the result is arguably more correct in the OO version.

This is a problem lots of folks (including me) hit when working with mutable state so I'll try to find a better example to demonstrate it.

To answer your question about why I thought 16 was correct:

I was using equational reasoning to run the example in my head. In other words, if I were to replace each variable with its value (knowing numbers don't have breed/conjoin) I was interpreting it as:

var result = 4.conjoin(0).breed(2).conjoin(4.breed(2)).seagulls;
var result = 4.breed(2).conjoin(8).seagulls;
var result = 8.conjoin(8).seagulls;
var result = 16;

from mostly-adequate-guide.