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!