Benoit Daloze wrote:
> 2010/1/24 Marnen Laibow-Koser <marnen / marnen.org>:
>> def initialize(options, &proc)
>>>  def to_s
>>>   name || 'unnamed_variable'
>>>  end
>>> end
>>
>> ...and these can stay the same.
>>
> 
> Thank you for your answer. I know that class checking is not so OO.

It's very OO.  It's just not very Rubyish.

> The old behavior was like you propose: using a Hash. and then we were 
> using
> @name, @value = options.values_at(:name, :value) # values_at is really
> nice here :)
> 
> That's a very cool approach except it's really longer and I think it's
> significant in this context.
> We are writing a math library, this class represent a mathematical
> variable,

Why do you need a separate class for this, instead of using Ruby's 
variable mechanism?

> so here we have:
> 
> x = var :x, 3                                 # with my way
> x = var name: :x, value: 3            # with hash, in 1.9
> x = var :name => :x, :value => 3 # with hash, in 1.8 (not relevant)
> To specify the name is already redundant with the real var name. It's
> possible via caller to get it, with parsing, but that's not a very
> good way neither. (Would you support that?)

No, that seems bad.  I think you have three good choices for the 
constructor, then:
* Define the arguments positionally so that it's always new(name, value)
* Pass a short hash: new(:x => 3)
* Use method_missing: x = Variable.x(3)

> 
> So much checking in a case statement for classes looks bad, but it was
> intended to raise an ArgumentError if we still used the old behavior.
>

Then just check for a Hash!

Or better yet, support both syntaxes.

> So, could I have your opinion, if we forget about Hash because it
> looks too long here ?

I don't think that's a great reason to drop it, but see above for other 
ideas.

> Thank you for your answer again.

Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen / marnen.org
-- 
Posted via http://www.ruby-forum.com/.