Forum: Ruby If like smalltalk

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
71f1b6b2c3fd9af2e8c52618fb91caa6?d=identicon&s=25 Jules Jacobs (jules)
on 2005-11-30 22:13
Hi, I have a question about Ruby if constructs. Why aren't they like
smalltalk if's, where you have a boolean class and two subclasses: true
and false. They both have these methods: ifTrue and ifFalse. If you use
a block with a ifTrue on a True object, it will be yielded. If you use
it on a false object, nothing will happen.

So in ruby code:

true.if_true do
#code will be executed
end

and:
false.if_true do
#code will NOT be executed
end

and if_false is available too.

so you can do this too:

(var == 'a').if_true do
puts 'var = "a"'
end

I know it would be difficult to do an if-else thing with this because
the return value from the block would be the receiver:

(var == 'a').if_true do
   puts 'var = "a"'
end.if_false do
   #code
end

So is this the reason for if(var == 'a') not being syntactic sugar for
(var == 'a').if_true?

Thanks for answering!

Jules
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 halostatue (Guest)
on 2005-11-30 22:23
(Received via mailing list)
On 11/30/05, Jules Jacobs <julesjacobs@gmail.com> wrote:
> Hi, I have a question about Ruby if constructs. Why aren't they like
> smalltalk if's, where you have a boolean class and two subclasses: true
> and false. They both have these methods: ifTrue and ifFalse. If you use
> a block with a ifTrue on a True object, it will be yielded. If you use
> it on a false object, nothing will happen.

They aren't like Smalltalk ifs because Ruby isn't Smalltalk. That
said, people have been able to make things that work remarkably
similar to the Smalltalk stuff. Do a search in the archives and you
should find it.

-austin
5a5dbce467c5b43ad8fc81209db607b3?d=identicon&s=25 daniel.cedilotte (Guest)
on 2005-11-30 22:35
(Received via mailing list)
Jules Jacobs wrote:

>end
>(var == 'a').if_true do
>end
>
>So is this the reason for if(var == 'a') not being syntactic sugar for
>(var == 'a').if_true?
>
>Thanks for answering!
>
>Jules
>
>
>
What would be the point of creating another smalltalk like language?
smalltalk is still active as far as I can tell, so if you like
smalltalk, why not use that instead of ruby? I don't want the ifs to be
like smalltalk if. I want standard ifs.
10d9ed7ab11115b081bb36f56a7a13bc?d=identicon&s=25 johnwilger (Guest)
on 2005-11-30 22:35
(Received via mailing list)
On 11/30/05, Jules Jacobs <julesjacobs@gmail.com> wrote:
> end
>
> and:
> false.if_true do
> #code will NOT be executed
> end

Just do this:

-- BEGIN --
class Object
  def if_true(&block)
    block.call if self
    self
  end

  def if_false(&block)
    block.call unless self
    self
  end
end
-- END --

> (var == 'a').if_true do
>    puts 'var = "a"'
> end.if_false do
>    #code
> end

The above modifications to Object will allow this to work as well.

(Although I feel it necessary to add: that particular syntax is just,
well, horrid. The only possible advantage is variable scoping, and
even then there's probably a better way to express what you want.)

--
Regards,
John Wilger
http://johnwilger.com
1e7d80da752f10d223599a3600aed1d2?d=identicon&s=25 srinivas.j (Guest)
on 2005-12-01 01:45
(Received via mailing list)
An interesting difference, though, is that the Smalltalk version
utilizes the language's capability to accept multiple blocks in a method
call -- 'ifTrue: [ ... ] ifFalse: [ ... ]'.  In the Ruby version given,
it needs to have a (may be) hack to return the value of the original
condition, from the 'if' block.

JS
28dc1d776c662ecac6166d4fd704783c?d=identicon&s=25 lazax.com (Guest)
on 2005-12-01 02:17
(Received via mailing list)
You can define these methods in TrueClass and FalseClass so you don't
polute the Object class.

class TrueClass
    def if_true? ...; end
    def if_false?...; end
end

class FalseClass
   # the opposite...
end
10d9ed7ab11115b081bb36f56a7a13bc?d=identicon&s=25 johnwilger (Guest)
on 2005-12-01 04:39
(Received via mailing list)
On 11/30/05, Laza <lazax.com@gmail.com> wrote:
> You can define these methods in TrueClass and FalseClass so you don't
> polute the Object class.

I had thought about doing it that way, but then you could only use
that syntax on actual instances of TrueClass and FalseClass -- if
statements are quite often applied to arbitrary objects since, IIRC,
everything other than FalseClass and NilClass is the same as true for
that purpose.

--
Regards,
John Wilger
http://johnwilger.com
Ede7f0028025fb88b47dda1a8c38be42?d=identicon&s=25 lthiryidontwantspams (Guest)
on 2005-12-01 13:05
(Received via mailing list)
Jules Jacobs a écrit :
> end
> (var == 'a').if_true do
> end
>
> So is this the reason for if(var == 'a') not being syntactic sugar for
> (var == 'a').if_true?
>
> Thanks for answering!
>
> Jules
>

(var == 'a').if_true?
is parsed as a method call and then needs a method dispatch

if var =='a'
is an unambigous imperative instruction and then already understood at
parse time


SmallTalk is intellectually pure OO, while Ruby is purely practical OO
hence the difference. :)

--
Lionel Thiry

Personal web site: http://users.skynet.be/lthiry/
7a7777470c11f6c746e3236a1b3aa4db?d=identicon&s=25 steve.enzer (Guest)
on 2005-12-02 01:37
(Received via mailing list)
I'm not sure if I'm understanding your question, but it's actually
easier than it was in Smalltalk.

In Ruby, everything but nil and False evaluates to true. There's no
ifTrue: because you don't need one. You can say if anything then
anything, and postconditions are supported too.

For example (Pseudo-Smalltalk in parens)


  if group.members then group.some_action end
(members isNil ifFalse: [some_action])
  unless group.save then some_action end
(group save ifTrue: [someAction]
  some_action if  !group.empty?  -- postcondition
(group isEmpty ifFalse: [someAction])

I'm finding it clearer and more terse than Smalltalk, with no added
limitations
This topic is locked and can not be replied to.