Re: ruby-dev summary 28206-28273


#1
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


#2

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. - removed_email_address@domain.invalid - http://segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com


#3

Berger, Daniel removed_email_address@domain.invalid 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