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