From: Einar Date: 2006-03-10T17:38:44+09:00 Subject: Re: [Newbie] Immutable objects George Ogata wrote: > Einar writes: > > >>Robert Klemme wrote: >> >>>Einar H�st wrote: >>>It's not sufficient, you'll have to freeze those strings, too. Note >>>that >>>this will freeze the originals which probably is a bad idea. You could do >>>def ini(suit, rank) >>> @suit = suit.dup.freeze >>> @rank = rank.dup.freeze >>> freeze >>>end >>> >> >>Ah, I see - in C# "where I come from", strings are immutable. Of >>course, no-one will be using this code except me, so I'm definitely >>conjuring imaginary problems here - but at the same time, the whole >>point of this project is to learn about the language :-) > > > For things like @suit -- which I take it can only take one of four > enumerated values -- I think it's actually more rubyesque to use > symbols. e.g.: > > @suit = :spade > > This has the side benefit that Symbols themselves are effectively > immutable. > > But as Robert and James hinted, freezing is seldom used. It's like > type-checking: you can be a complete nazi about banning anything out > of line, but (a) you lose elegance and simplicity of code and (b) your > tests should probably be checking this anyway. YMMV. Thanks - this is starting to feel like playing an adventure game where the map of the terrain becomes visible as I explore it (or rather: as you tell me about it). It looks like symbols are appropriate here. I'm thinking the same might be the case for rank (e.g. "card value" from 2 up to ace). It might look weird for the numeric values (e.g. :2 or :3 - which might not even be legal? but then :two and :three would), but not so for e.g. :jack or :queen. I'm a bit ambivalent on the strictness issue. I buy your arguments for a) simplicity and b) testing over typing (Bruce Eckel wrote an article on that, which made a lot of sense to me). At the same time, I'm still carrying scars from having a few leaks in the abstractions for a data access API I wrote in my previous job... - Einar