2009/10/14 ara.t.howard <ara.t.howard / gmail.com>:
>
>
> On Oct 13, 3:13 ¨Âí¬ Òïâåòô Ëìåííå ¼óèïòôãõô®®®Àçïïçìåíáéì®ãïí¾ ÷òïôåº
>
>>
>> Concluding from the complexity you attribute to the problem I assume
>> you can provide more of those guiding questions.  ¨Âîã÷å èáöå ãïííïî
>> understanding what the problem is we can start to think about
>> solutions.
>>
>
> sorry i missed your post.  ¨Â ôèéîíù çõéäåìéîåó áòðòïâáâìù
> summarized most accurately here:
>
> http://rubyquiz.com/quiz67.html
>
> and here
>
> http://github.com/ahoward/fattr
>
> specifically the README and tests

Thanks for the pointers!  Now that looks quite specific.  It seems
fattr is a superset of the koan list, correct?

I noticed a few things about your koans (a quite nice way to formulate
the spec btw.): in koan 8 and 9 you have two default values.  It might
be easier for readers and technical validation if there would be two
different values; then there cannot be any confusion which value is
inherited where.  Also, I believe tests like "assert{ (o.a = nil) ==
nil }" should better be rewritten as

o.a = nil
assert{ o.a == nil }

Because Ruby guarantees that the assignment will always return the
rvalue which makes the original assert infallible.

09:11:41 ~$ allruby -e 'o="";def o.a=(x) 123 end; p(o.a=99)'
CYGWIN_NT-5.1 padrklemme1 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin
========================================
ruby 1.8.7 (2008-08-11 patchlevel 72) [i386-cygwin]
99
========================================
ruby 1.9.1p129 (2009-05-12 revision 23412) [i386-cygwin]
99
09:12:26 ~$

> the really relevant bit is that this
>
>  ¨Âïäõì>  ¨Âîèåòôéáâìåßáôôòéâõôå ºø
>  ¨Âîä
>
>  ¨Âìáóó >  ¨Âøôåî>  ¨Âîä
>
> needs to do something sane.

Sane is good, but where does insanity start? :-)

>  ¨Â áìóï æååì ôèáô áîãïðùéîæòïí ôè> parent (aka inheriting state) should be deferred untill the value is
> actually referenced, otherwise very surprising things happen.

On first inspection I think I like the koans better than fattr which
seems like the swiss army knife of attribute definition because fattr
provides rich functionality.  While this is generally a good thing,
the difference in complexity to the attr_* family of methods is
significant.  If time permits I will play a bit with this to get a
better feeling.  Thanks again!

Kind regards

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/