On 2009-11-17, Marnen Laibow-Koser <marnen / marnen.org> wrote: >== means "conceptually the same thing", I think. Not necessarily the > same object reference -- but equivalent. Hmm. I guess I think of == as more like "functionally the same". Two 14s function the same way. If the question is "who is stronger", then if both characters have a current functional strength of 14, it's a tie. But that doesn't make them the same object. Basically: 14.0 == 14. That doesn't mean they're the same thing, because obviously they're different things. And they're not even quite equivalent; 15 / 14.0 is not the same as 15 / 14. But they're still equal, because they have the same value. > How you define "values are the same" is up to you. I think it's best to > consider it as meaning total equality for both base and modifiers. I don't, though, because the only reason to be comparing two values is to see whether one is larger than the other -- say, whether one creature is stronger than another. > Right. But two stats which have the same base and modifiers *are* the > same thing, aren't they? I don't think so. Even if john and mary both have the same base strength, and the same modifiers, they're not the same thing -- making john stronger doesn't make mary stronger. > That's not the way Ruby references work. You can obtain a reference to > the object returned by john.strength at a given time, but you can't know > whether john.strength will always return that same object. Right -- which is why my initial plan was to commit that, after initialize(), john.strength DOES always yield the same object, no matter what changes are made to its value. >> So when the modifiers change, your solution would be to replace the >> entire >> object, duplicating its whole set of modifiers and other state? > Yes. That is the best way of handling value objects -- in fact, it's > the way Ruby handles Fixnums! This sounds extremely expensive for an extremely commonplace thing. In an ordinary turn of a game, I might have thirty or forty modifiers which change, meaning that I'd be duplicating-but-modifying non-trivial object trees thirty or forty times. > Object 1 is the Fixnum 1, and object 13 is the Fixnum 6. When the value > of a changes, the variable a holds an entirely different object > reference. Yes, I know that. But I don't think a stat is a value. I think it's a complicated model, which happens to yield a value. > Then maybe a statistic should be composed of several value objects. I > was operating under the assumption that it's just a base Fixnum and a > Hash containing a few modifier Fixnums. What else is there? History of previous values (in some cases), and the modifiers aren't fixnums; they're name/value pairs probably plus other traits such as a duration (some expire, some don't). There will probably be more tweaks to that over time. > From what you've described, Stat isn't large and complicated. What's > missing from your description? As time goes on, stats are expected to be much more complicated. A stat will likely have its original starting base value, its highest recorded base value, and a set of modifiers (which may change quite often). Possibly more things beyond those. So right now, I think it is probably nearly-sanest for me to have it delegate nearly everything to the fixnum current value, which really is a value object. So it isn't a value, but it delegates to one. Basically, anything that has internal state to keep track of which is not part of how you use it strikes me as not really being a value, even if it looks like one from the outside. That said! I am thinking that perhaps it should *present* as immutable -- that is, I should not define john.strength = 15 in any way, but rather, if you want to ask it to change its value, you have to send it messages. So instead of john.strength += 1, you'd write john.strength.adjust_by(1). Hmm. I suppose the thing, then, would be to simply not provide a strength= method for the things that have stats. -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!