I'm not sure we even need the 'with' syntax. Even if we do, it breaks
the programmers context in a way that we might not want to have to
explain constantly. I can just hear the questions now...
"Why are my method calls inside a with being executed on the wrong object?"
"Well, thats because with changes self for it's body, and so you have
to be careful what you call in there."
repeat..
While the more hardcore of us are use to using blocks to enter into
new and strange contexts (module_eval/class_eval/instance_eval oh
my!), pushing this to the normal user is not a decision that should be
made lightly.
As for the original syntax "&?" I'm against it. It adds a significant
new level of unreadability. At this stage of the game, any syntax
changes need to really thought out. We've already got a great,
expressive syntax. If you want to do away with the duplication of
effort, use a local variable, thats what there there for:
if t = a[0] and t.strip.empty?
# jump off a bridge
end
On a regular basis I write:
if a = something_long
a.another_operation
end
The local variable a gets the value "cached" and then we get to do a
conditional on it's value right away. We've got a language where
everything is an expression, lets use it!
- Evan
On 2/3/06, James Britt <ruby / jamesbritt.com> wrote:
> mathew wrote:
> >...
>
>
> > with a[1]
> > strip!
> > empty?
> > end
> >
> > or similar. Hopefully you get the basic idea anyway, and someone can
> > refine the semantics if they like it...
>
>
> I'm not too keen on terse syntax; clarity for the read takes precedence
> over ease for the writer. The 'with' syntax is more expressive.
>
>
> James
>
>
>
--
When I do good, I feel good; when I do bad, I feel bad,
and that is my religion.
-- Abraham Lincoln (1809 - 1865)