[#15359] Timeout::Error — Jeremy Thurgood <jerith@...>

Good day,

41 messages 2008/02/05
[#15366] Re: Timeout::Error — Eric Hodel <drbrain@...7.net> 2008/02/06

On Feb 5, 2008, at 06:20 AM, Jeremy Thurgood wrote:

[#15370] Re: Timeout::Error — Jeremy Thurgood <jerith@...> 2008/02/06

Eric Hodel wrote:

[#15373] Re: Timeout::Error — Nobuyoshi Nakada <nobu@...> 2008/02/06

Hi,

[#15374] Re: Timeout::Error — Jeremy Thurgood <jerith@...> 2008/02/06

Nobuyoshi Nakada wrote:

[#15412] Re: Timeout::Error — Nobuyoshi Nakada <nobu@...> 2008/02/07

Hi,

[#15413] Re: Timeout::Error — Jeremy Thurgood <jerith@...> 2008/02/07

Nobuyoshi Nakada wrote:

[#15414] Re: Timeout::Error — Nobuyoshi Nakada <nobu@...> 2008/02/07

Hi,

[#15360] reopen: can't change access mode from "w+" to "w"? — Sam Ruby <rubys@...>

I ran 'rake test' on test/spec [1], using

16 messages 2008/02/05
[#15369] Re: reopen: can't change access mode from "w+" to "w"? — Nobuyoshi Nakada <nobu@...> 2008/02/06

Hi,

[#15389] STDIN encoding differs from default source file encoding — Dave Thomas <dave@...>

This seems strange:

21 messages 2008/02/06
[#15392] Re: STDIN encoding differs from default source file encoding — Yukihiro Matsumoto <matz@...> 2008/02/06

Hi,

[#15481] very bad character performance on ruby1.9 — "Eric Mahurin" <eric.mahurin@...>

I'd like to bring up the issue of how characters are represented in

16 messages 2008/02/10

[#15528] Test::Unit maintainer — Kouhei Sutou <kou@...>

Hi Nathaniel, Ryan,

22 messages 2008/02/13

[#15551] Proc#curry — ts <decoux@...>

21 messages 2008/02/14
[#15557] Re: [1.9] Proc#curry — David Flanagan <david@...> 2008/02/15

ts wrote:

[#15558] Re: [1.9] Proc#curry — Yukihiro Matsumoto <matz@...> 2008/02/15

Hi,

[#15560] Re: Proc#curry — Trans <transfire@...> 2008/02/15

[#15585] Ruby M17N meeting summary — Martin Duerst <duerst@...>

This is a rough translation of the Japanese meeting summary

19 messages 2008/02/18

[#15596] possible bug in regexp lexing — Ryan Davis <ryand-ruby@...>

current:

17 messages 2008/02/19

[#15678] Re: [ANN] MacRuby — "Rick DeNatale" <rick.denatale@...>

On 2/27/08, Laurent Sansonetti <laurent.sansonetti@gmail.com> wrote:

18 messages 2008/02/28
[#15679] Re: [ANN] MacRuby — "Laurent Sansonetti" <laurent.sansonetti@...> 2008/02/28

On Thu, Feb 28, 2008 at 6:33 AM, Rick DeNatale <rick.denatale@gmail.com> wrote:

[#15680] Re: [ANN] MacRuby — Yukihiro Matsumoto <matz@...> 2008/02/28

Hi,

[#15683] Re: [ANN] MacRuby — "Laurent Sansonetti" <laurent.sansonetti@...> 2008/02/28

On Thu, Feb 28, 2008 at 1:51 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

Re: [ANN] MacRuby

From: "Laurent Sansonetti" <laurent.sansonetti@...>
Date: 2008-02-29 04:49:19 UTC
List: ruby-core #15693
On Thu, Feb 28, 2008 at 6:19 PM, Rick DeNatale <rick.denatale@gmail.com> wrote:
> On 2/28/08, Richard Kilmer <rich@infoether.com> wrote:
>  >
>  >  On Feb 28, 2008, at 7:44 PM, Evan Phoenix wrote:
>
> >  > At one point, I had a small parser change that allowed this to be
>  >  > written as:
>  >  >
>  >  > O[duck foo: 1, bar: 2]
>  >  >
>  >  > The idea was that the rubinius compiler would detect this special
>  >  > form and emit the 'right thing'.
>  >  >
>  >  > I think a bit part of this is whether you expect users (and other
>  >  > code) to know they're calling out to Objective-C, or if you want
>  >  > tight integration. This is essential what matz says.
>  >  >
>  >  > By making special Objective-C syntax, then you can't pass in an
>  >  > Objective-C object and expect it to be duck-typed like normal ruby
>  >  > objects. But the trade off is that the syntax is less elegant. I
>  >  > think it's a trade off, and my 2 cents is you should opt for the
>  >  > more elegant syntax. This is because there are only a few tiny edge
>  >  > cases where the Objective-C selector matches the ruby selector,
>  >  > where you'd want to allow the ObjC object to be duck typed as
>  >  > something else.
>  >
>  > So in your view:
>  >
>  >         O[duck foo:1, bar:2]
>  >
>  > is elegant?  Elegant Ruby? no.  I agree to opt for the elegant syntax
>  >  and that's:
>  >
>  >         duck foo:1, bar:2
>  Or
>
>           duck foo: 1 bar: 2
>
>  which is even more elegant, since it's the same syntax as Smalltalk <G>
>

The problems with these syntaxes are that it's hard to parse them, and
that they can lead to ambiguities when wrongly used.

For example,

  duck.foo: x, with: y

could be written by mistake as

  duck.foo :x, with: y

which has a completely different meaning.

Also, when the parenthesizes are omitted, it may be hard to correctly
parse (assuming that you want to send the message to self)

  foo:x, with:y

That's why I think that the following is the best compromise so far,
between readability and reliability.

  foo x, with:y # or foo(x, with:y)

Laurent

In This Thread