[#2529] concerns about Proc,lambda,block — "David A. Black" <dblack@...>

Hi --

39 messages 2004/03/01
[#2531] Re: concerns about Proc,lambda,block — ts <decoux@...> 2004/03/01

>>>>> "D" == David A Black <dblack@wobblini.net> writes:

[#2533] Re: concerns about Proc,lambda,block — "David A. Black" <dblack@...> 2004/03/01

Hi --

[#2537] Re: concerns about Proc,lambda,block — matz@... (Yukihiro Matsumoto) 2004/03/01

Hi,

[#2542] Re: concerns about Proc,lambda,block — Mathieu Bouchard <matju@...> 2004/03/02

[#2545] Re: concerns about Proc,lambda,block — matz@... (Yukihiro Matsumoto) 2004/03/02

Hi,

[#2550] Re: concerns about Proc,lambda,block — Mauricio Fern疣dez <batsman.geo@...> 2004/03/03

On Wed, Mar 03, 2004 at 07:51:10AM +0900, Yukihiro Matsumoto wrote:

[#2703] Proposed patch to add SSL support to net/pop.rb — Daniel Hobe <daniel@...>

This patch adds support to Net::POP for doing POP over SSL. Modeled on how

19 messages 2004/03/27
[#2704] Re: Proposed patch to add SSL support to net/pop.rb — Daniel Hobe <daniel@...> 2004/03/27

This is v2 of the patch. Cleaned up a bit and added some more docs.

[#2707] Re: Proposed patch to add SSL support to net/pop.rb — Daniel Hobe <daniel@...> 2004/03/28

v3 of the patch:

[#2721] Re: Proposed patch to add SSL support to net/pop.rb — Minero Aoki <aamine@...> 2004/03/30

Hi,

Re: Duck typing chapter

From: Dave Thomas <dave@...>
Date: 2004-03-06 03:09:19 UTC
List: ruby-core #2598
On Mar 5, 2004, at 17:44, Warren Brown wrote:

>     One thing that stuck out to me is that after explaining that in 
> Ruby
> the class is not the type, the class Roman tests the class of its
> parameters (i.e. "if Integer === other").  In this case you could (and
> probably will) argue that the class *is* the type, but this should
> probably be specifically stated to the reader to avoid confusion.

Well, I think I'd probably say that we're interested in the class here, 
not the type. The classes contain the implementation of methods sych as 
'+', are we're trying to determine is we have compatible a compatible 
receiver and argument for addition. So I'm not really interested in the 
type as much as I am in the implementation.

Does that make sense?

>
>     I'm sure you'll find all of the easy typos, but there is a subtle
> one in the Roman#initialize method (no not the "muts" one).  The error
> message should say "<= #{MAX_ROMAN}", not "< #{MAX_ROMAN}".
>

Oh! Good catch.

>     The only other thing that struck me as odd was the assumption in
> Roman#coerce that any parameter that is not a Fixnum should be 
> converted
> to a Float.  This seems a bit simplistic, especially with Bignum as a
> built-in class, and would seem to preclude using some other 
> Integer-like
> class (Chinese number?).  Perhaps a check for a to_int method would be
> more appropriate?
>

This whole example is screwy, but let me tell you my initial reasoning.

If the argument is a Roman number, then the result might be a Roman 
number.

If the result is a Fixnum, then the result might be a Roman number

But is the argument is a bignum or anything else, the result can't be a 
Roman number (because bignums would be too big).

I can't test for to_int, because that would lose precision (Float 
supports to_int, which I'm going to post about separately).

Having said that, the more I look at this code, the less I like it. 
Roman numbers are representations, and don't really support arithmetic 
directly.

Time for a new example, methinks


Cheers

Dave


In This Thread