As an alternative to:
a = y == z ? b : c
we can say:
a = (b if y == x) || c
Can anyone think of others?
I'd really like to be able to say:
a = b if y==z otherwise c
but the precedence of _or_ is not low enough for this to work. Would
changing the precedence of _or_ to be lower than expression modifiers
brake much? I believe _or_ is presently just above the expression
modifiers today. Then again perhaps that would be confusing. Perhaps
an _otherwise_ operator would do the trick.
This is trivial really, but ruby specializes in niceties which many
might deem trivial but which all add up to an amazingly productive
environment.
···
--
John-Mason Shackelford
Software Developer
Pearson Educational Measurement
2510 North Dodge St.
Iowa City, IA 52245
ph. 319-354-9200x6214
john-mason.shackelford@pearson.com
http://pearsonedmeasurement.com
As an alternative to:
a = y == z ? b : c
we can say:
a = (b if y == x) || c
Can anyone think of others?
I'd really like to be able to say:
a = b if y==z otherwise c
but the precedence of _or_ is not low enough for this to work. Would
changing the precedence of _or_ to be lower than expression modifiers
brake much? I believe _or_ is presently just above the expression
modifiers today. Then again perhaps that would be confusing. Perhaps
an _otherwise_ operator would do the trick.
Is this not called the 'else' operator? 
This is trivial really, but ruby specializes in niceties which many
might deem trivial but which all add up to an amazingly productive
environment.
John-Mason Shackelford
E
···
Le 11/5/2005, "John-Mason P. Shackelford" <jpshack@gmail.com> a écrit:
--
template<typename duck>
void quack(duck& d) { d.quack(); }
I'd really like to be able to say:
a = b if y==z otherwise c
How about:
a = if (y == z) then b else c end
Paul.
I like this one:
a = if condition then x else y end
and same way:
a = case condition when branch_x : value_x when branch_y : value_y
else other_value end
···
On 5/12/05, John-Mason P. Shackelford <jpshack@gmail.com> wrote:
As an alternative to:
a = y == z ? b : c
we can say:
a = (b if y == x) || c
Can anyone think of others?
I'd really like to be able to say:
a = b if y==z otherwise c
but the precedence of _or_ is not low enough for this to work. Would
changing the precedence of _or_ to be lower than expression modifiers
brake much? I believe _or_ is presently just above the expression
modifiers today. Then again perhaps that would be confusing. Perhaps
an _otherwise_ operator would do the trick.
This is trivial really, but ruby specializes in niceties which many
might deem trivial but which all add up to an amazingly productive
environment.
--
John-Mason Shackelford
Software Developer
Pearson Educational Measurement
2510 North Dodge St.
Iowa City, IA 52245
ph. 319-354-9200x6214
john-mason.shackelford@pearson.com
http://pearsonedmeasurement.com
--
http://nohmad.sub-port.net
a = if y == z then b else c end
martin
···
John-Mason P. Shackelford <jpshack@gmail.com> wrote:
As an alternative to:
a = y == z ? b : c
we can say:
a = (b if y == x) || c
Can anyone think of others?
John-Mason P. Shackelford wrote:
...
I'd really like to be able to say:
a = b if y==z otherwise c
Just kidding:
class Object
def incase(cond)
if cond
self
else
yield
end
end
end
a = 3.incase(1==2) {"c"}
p a
a = 3.incase(1==1) {"c"}
p a
I don't believe one can use _else_ with an expression modifier. If we
try to use an if block in this case, things get ugly fast:
a = if y == x; b; else; c; end
Of course I may be missing something. I need to read more code than
just my own :s
···
--
John-Mason Shackelford
Software Developer
Pearson Educational Measurement
2510 North Dodge St.
Iowa City, IA 52245
ph. 319-354-9200x6214
john-mason.shackelford@pearson.com
http://pearsonedmeasurement.com
That's only lazy in its second argument Maybe
def only(&block)
block
end
class Proc
def if(arg)
arg ? self.call : arg
end
end
class Object
def then
self ? yield : self
end
def else
self ? self : yield
end
alias :otherwise :else
end
p (1==1).then { 5 }.else { 1/0 }
p only {1/0}.if(1 == 2).otherwise { 4 }
martin
···
Joel VanderWerf <vjoel@path.berkeley.edu> wrote:
Just kidding:
class Object
def incase(cond)
if cond
self
else
yield
end
end
end
a = 3.incase(1==2) {"c"}
p a
a = 3.incase(1==1) {"c"}
p a
The if ... then ... else ... end statements people have been posting are perfectly legal Ruby. Fire up irb an give them a spin. It's basically just collapsing an if statement to one line, then capturing the proper return (since statements return things in Ruby). The "then" is just a pretty replacement for the ; here.
Hope that helps.
James Edward Gray II
···
On May 11, 2005, at 2:37 PM, John-Mason P. Shackelford wrote:
I don't believe one can use _else_ with an expression modifier. If we
try to use an if block in this case, things get ugly fast:
a = if y == x; b; else; c; end
Of course I may be missing something. I need to read more code than
just my own :s
Yeah, that was the the point.
If (x == y) then a = b else c end
is equivalent to x == y and a = b or c
···
On 5/11/05, David A. Black <dblack@wobblini.net> wrote:
Hi --
On Thu, 12 May 2005, Logan Capaldo wrote:
> On 5/11/05, John-Mason P. Shackelford <jpshack@gmail.com> wrote:
>> As an alternative to:
>>
>> a = y == z ? b : c
>>
>> we can say:
>>
>> a = (b if y == x) || c
>>
>> Can anyone think of others?
>
> Heres one way:
>
> x == y and a = b or c
In the case where x != y, that expression will just return c, without
assigning it to a. (I learned this the hard way either here or on IRC
recently
David
--
David A. Black
dblack@wobblini.net
I'd prefer it with less ;'s as well:
a = if (y==z): b else c end
which works perfectly fine:
irb(main):025:0> a = if (1==2): 'foo' else 'bar' end
=> "bar"
I really don't like the idea of having an else/otherwise/whatever
operator that allows the results of the statement to be the first and
last pieces, and the operators and conditions all squished in the
middle. B if A else C doesn't read well to me, and would get
confusing I think, whereas if A then B else C is very natural.
Jason
···
On 5/11/05, James Edward Gray II <james@grayproductions.net> wrote:
On May 11, 2005, at 2:37 PM, John-Mason P. Shackelford wrote:
> I don't believe one can use _else_ with an expression modifier. If we
> try to use an if block in this case, things get ugly fast:
>
> a = if y == x; b; else; c; end
>
> Of course I may be missing something. I need to read more code than
> just my own :s
The if ... then ... else ... end statements people have been posting
are perfectly legal Ruby. Fire up irb an give them a spin. It's
basically just collapsing an if statement to one line, then capturing
the proper return (since statements return things in Ruby). The
"then" is just a pretty replacement for the ; here.
Hope that helps.
James Edward Gray II
if you wanted to assign to a the result of the expression just like a
?: you'd do
a = (y == x and b) or c
unfortunately you have to use the parens in this case
you could also do y == x and a = b or a = c
···
On 5/11/05, Logan Capaldo <logancapaldo@gmail.com> wrote:
On 5/11/05, David A. Black <dblack@wobblini.net> wrote:
> Hi --
>
> On Thu, 12 May 2005, Logan Capaldo wrote:
>
> > On 5/11/05, John-Mason P. Shackelford <jpshack@gmail.com> wrote:
> >> As an alternative to:
> >>
> >> a = y == z ? b : c
> >>
> >> we can say:
> >>
> >> a = (b if y == x) || c
> >>
> >> Can anyone think of others?
> >
> > Heres one way:
> >
> > x == y and a = b or c
>
> In the case where x != y, that expression will just return c, without
> assigning it to a. (I learned this the hard way either here or on IRC
> recently
>
> David
>
> --
> David A. Black
> dblack@wobblini.net
>
>
Yeah, that was the the point.
If (x == y) then a = b else c end
is equivalent to x == y and a = b or c
Is this really better than:
a = (y==z) ? b : c
?
The tertiary operator ?: can be used if you want
something terse and "if then else end" if you want something
more verbose. I'm not sure I see the need for yet another
variation.
Gary Wright
···
On May 11, 2005, at 4:07 PM, Jason Foreman wrote:
I'd prefer it with less ;'s as well:
a = if (y==z): b else c end
Jason,
a = b if y==z else c
I really don't like the idea of having an else/otherwise/whatever
operator that allows the results of the statement to be the first and
last pieces, and the operators and conditions all squished in the
middle. B if A else C doesn't read well to me, and would get
confusing I think, whereas if A then B else C is very natural.
A year ago I would have agreed with you whole heartedly, but I've
come to believe that some thoughts are better expressed with an
expression modifier rather than an if block. When I am trying to
emphasize an assignment, rather than a branch in execution flow,
conditional expressions fit the bill nicely where the subordination of
an if block (inline or not) distracts the reader from the flow of the
code. The syntax below clearly expresses that my main intent with this
line of code is the assignment a = b and if the reader cares to know
more detail about that assignment he can see that in the ordinary case
the assignment is performed when a given condition is true, though
some provision is made if it isn't.
I find myself wanting this as code evolves:
1. a = b
2. a = b if y==z
3. if y==z then a else b end
- or -
3. y==z ? a : b
Here at step three my main intent (the assignment) is now subordinated
to the condition, which in this case is of secondary concern. While in
some contexts emphasizing the branch will be most clear, in others it
would distract the reader from more important aspects of the code.
Like any language feature this syntax could be abused, but I submit
that expression modifiers exist not to save keystrokes, but to convey
a thought different from that communicated by an if block. The
expressive power of a richer expression modifier would help me to code
what I mean--which is exactly what we want out of a programming
language.
John-Mason Shackelford
Software Developer
Pearson Educational Measurement
2510 North Dodge St.
Iowa City, IA 52245
ph. 319-354-9200x6214
john-mason.shackelford@pearson.com
http://pearsonedmeasurement.com
I agree, I don't want another operator, when the existing ones are
more than sufficient. I personally try never to use the tertiary
operator anyway, because when I come back to read it later its not
always immediately obvious to me, but "if else end" always is obvious.
Jason
···
On 5/11/05, gwtmp01@mac.com <gwtmp01@mac.com> wrote:
On May 11, 2005, at 4:07 PM, Jason Foreman wrote:
>
> I'd prefer it with less ;'s as well:
>
> a = if (y==z): b else c end
Is this really better than:
a = (y==z) ? b : c
?
The tertiary operator ?: can be used if you want
something terse and "if then else end" if you want something
more verbose. I'm not sure I see the need for yet another
variation.
Gary Wright
>
> I'd prefer it with less ;'s as well:
>
> a = if (y==z): b else c end
Is this really better than:
a = (y==z) ? b : c
?
A little, for readability. I like using actual words as operators
whenever possible. This is, of course, excepting symbolic operators
like + and -, which I learned back in first grade, and carry as much
meaning as actual words.
The tertiary operator ?: can be used if you want
something terse and "if then else end" if you want something
more verbose. I'm not sure I see the need for yet another
variation.
First of all, it's the ternary operator As for the "if then else
end" statement, the dangling "end" at the... uh, *end*, is a bit of an
eyesore. It's what makes me shy away from using inline conditionals
like that.
I've thought a couple times that it would be nice to have something
like "otherwise" available. I wonder if it would be too difficult for
the parser to parse these two snippets the same:
···
On 5/11/05, gwtmp01@mac.com <gwtmp01@mac.com> wrote:
On May 11, 2005, at 4:07 PM, Jason Foreman wrote:
----
a = if (y==z)
b
else
c
end
----
a = if (y==z) then b else c
----
That is, if else is on the same line as the code to execute if true,
with no semicolon, the "end" can be dropped. Or this, instead:
----
a = b if y==z else c
----
Can the parser definitively detect that the if...else is being used as
a statement modifier in this case?
Just some thoughts off the top of my head, here. I could easily waffle
on them if a good case is made against it.
cheers,
Mark