Seebs wrote:
> On 2009-11-16, Marnen Laibow-Koser <marnen / marnen.org> wrote:
>> Seebs wrote:
>>> I think it makes more sense that way.  It's a category of objects which
>>> have common additional methods they support, but which can be used in 
>>> nearly
>>> any context where you could use an integer.
> 
>> Then they should most likely be Integers.  Extend them either with 
>> module inclusion or by subclassing.
> 
> Hmm.  I tried subclassing, but perhaps incorrectly.  The problem is that
> it really is, internally, an object with several integers, but unless 
> you
> know that and care about it, all you need is one particular one of those
> integers.

Oh, then that's a different story.  In this case, delegation is probably 
the right thing to do.

> 
>> Yeah, but it's probably not conceptually right for this case.  Have you 
>> been following the thread about using mixins rather than declaring new 
>> classes?
> 
> Only sort of.
> 
>> If you use actual Integers as I suggested above, everything will Just 
>> Work with less effort, and your design will be clearer.
> 
> I'm curious about this, but I'm having a hard time wrapping my head
> around it.  So far as I can tell, unless the integer is a Bignum, it'll
> be a Fixnum -- which means that any two things with the same value
> are the same object, and so on.
> 
> But I don't want any two statistics which currently have the same 
> apparent
> value to be the same object -- because I need to be able to, say, tack 
> on
> a modifier to one of them and have it not affect the other.

Sure.  I didn't realize you were doing things like that.  And you're 
right that the singleton nature of Bignums makes them less flexible in 
this regard.

> 
> As an example, some hypothetical object might do something like:
> 
>   x = Stat.new(10)
>   y = Stat.new(10)
> 
>   x.adjust_to(15)
> 
> At this point, "x + 1" should be 16, and "y + 1" should be 11.  If I 
> tacked
> on a "+3" modifier to x, x would report itself as 18... But internally,
> it's a 15 and a +3.  18 is just its value for most purposes.
> 
> I can't figure out how to express that by subclassing Integer.

It's probably not worth it.  I didn't understand your structure 
originally.

> The stat
> has several integers, although one of them is the one you probably want 
> if
> you're trying to perform arithmetic on it.

Brian's suggestion of #coerce may be a good one.

> 
> (Note the "adjust_to" -- you can't, for obvious reasons, assign a new
> value with =.  Things which have stats define the attr= for those stats
> to use adjust_to.)

Philosophical point: many people (myself included, I think) believe that 
unlike entity objects (say, Player in your game), value objects should 
be immutable.  This means

class Stat
  def adjust_to(n)
    # bad:
      @base = n
    # good:
      Stat.new(n, @modifier)
  end
end

See http://c2.com/cgi/wiki?ValueObjectsShouldBeImmutable .  Among other 
things, this means you never have to worry about modifying an object 
referred to in multiple places.

> 
> -s

Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen / marnen.org
-- 
Posted via http://www.ruby-forum.com/.