Re: ruby-dev summary 28206-28273

h["key"] and h["key"].dispatch
h["key"].nil? {|h| h.dispatch }

This issue is still open.

Yuck. Looks like a hack from Perl6. Not Ruby-ish.

Syntactically, a method might look better than an operator:

a[1].if?.strip.empty?
a[1].maybe.strip.empty?
a[1].and.strip.empty?

martin

Looks better syntactically, but still has problems as Austin pointed
out.

I’d sooner accept “iff” (if and only if):

iff h[“key”].dispatch -> same as: h[“key”].dispatch if h[“key”]

But, the idea of adding new keywords doesn’t thrill me and I worry that
it’s too terse.

Regards,

Dan

On Feb 2, 2006, at 7:39 AM, Berger, Daniel wrote:

Yuck. Looks like a hack from Perl6. Not Ruby-ish.
Looks more like Smalltalk, but should be not_nil?.


Eric H. - [email protected] - http://segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com

Berger, Daniel [email protected] wrote:

a[1].if?.strip.empty?
a[1].maybe.strip.empty?
a[1].and.strip.empty?

martin

Looks better syntactically, but still has problems as Austin pointed
out.

Didn’t see that post :frowning: Hopefully it’ll show up on the ng side sometime
soon. The only problem I can see with it is that you get the method call
overhead even if it does nothing.

I’d sooner accept “iff” (if and only if):

iff h[“key”].dispatch -> same as: h[“key”].dispatch if h[“key”]

But, the idea of adding new keywords doesn’t thrill me and I worry that
it’s too terse.

My strong objection to this is that it breaks the “. binds more tightly
than anything else” rule.

martin

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs