On 2009-11-17, Marnen Laibow-Koser <marnen / marnen.org> wrote:
>> The problem is, I sort of want to be able to do things like:
>>   john.str.add_modifier("drunk", -3)

>> Because really, the fact that str is a stat *is* part of the intended
>> published interface.

> Then your clients will know that it's a Stat object, and expect to call 
> to_i on it.

Except that it's extremely annoying to have an object where, out of five
hundred uses, four hundred and ninety six need an extra ".to_i".

> I don't see anything wrong with that; you can overload Stat 
> + Fixnum and so on as we discussed earlier in this thread.

Yeah.

> But if you really want automatic, you can have it:
> class Stat
>   def to_int
>     self.to_i
>   end
> end

> (According to http://www.rubyfleebie.com/to_i-vs-to_int/ , to_int is 
> called automatically as necessary and will make your class act as an 
> Integer.  to_i, of course, will not do that.)

This turns out not to quite be the case, in experiments.  If I do that,
it works most of the time, but as an example:
	john.str + john.dex + john.con
doesn't work, because it can't figure out that ANY of them should be
integers.  I also end up having to define a bunch of additional operators;
for instance, if I want to be able to write "john.str + 3", I have to define
+ for Stat, even though "3 + john.str" would probably do the right thing.

>> Modifier is a class too, which can handle things like counting down its
>> duration, etcetera.
>> 
>> And a stat has a handful of them.

> OK...*these* are your value object candidates, perhaps.

Hmm.  Well, probably not -- modifiers have internal state (duration, which I
was thinking to indicate as a turn counter) which they want to update.  Maybe.
I could make them into values perhaps if I, say, calculated their expiration
rather than their duration.  Then, if you refresh a modifier, you make a new
one with a later expiration.  Hmm.

>> Ahh, but I don't necessarily care whether it's accurate, just whether I
>> have a record.

> If it's not accurate, then there's no point keeping a record.

There can be; see below.

> In either case, though, for this sort of functionality you don't 
> necessarily need a full-fledged history.

Right.  I pretty much meant a mini-history like that.

> Right.  It's now clear that your stat object is too complex to be a 
> simple immutable value object, although some of its components might 
> well be.

I'm sort of liking the idea of making modifiers into immutable values.  It
would actually make life simpler, I think.

> I don't think delegation will work here -- for one thing, you may not 
> need to store the total value in any actual instance variable.  Using 
> to_int or possibly coerce will work much better.

Delegation empirically *does* work, although it may not be the most efficient
or best choice of how to do things.  Stashing the total value in an instance
variable may be useful anyway; these things get looked up pretty often.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam / seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!