Sth. wrong with File.file? (or with me)

ruby-talk
61

unless a.nil?
....
end

-austin

···

On Fri, 12 Nov 2004 04:47:27 +0900, Logan Capaldo <logancapaldo@gmail.com> wrote:

Well I have written true? and false? methods in the past. Forgetting
the best implementation at the moment I use it because I find things
like:

if a.nil?.false?
   ....
end

more readable than

if not a.nil?
....
end

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

62

>> respectively. Thus, self == true and TrueClass === self (note the
>> inversion of parameters on the call to #===) are the same test.
>> You can more efficiently write what you want as:
>>
>> class Object
>> def true?
>> false
>> end
>>
>> def false?
>> false
>> end
>> end
> You might noticed from my previous posting, the reason to I want
> to have #true? and #false?

No, I didn't. Not anything convincing, at any rate. It seemed to
boil down to "I don't think that a == b is sufficiently OO", which
is certainly not a good reason, IMO. Why do you not like "a ==
true"?

Personal taste! May be I am fond of wired taste !!
Sorry for trying to share my wired taste with you.

> Example:
> a = true
> b = false
>
> using my 'class Object'
> a.true? -> true
> b.false? -> true
>
> using your 'class Object'
> a.true? -> false
> b.false? -> false
> which are wrong according to my proposed #true? and #false?

Not if you actually did what I said, which was *NOT* just adding
#true? and #false? to Object. Look again; it does what you want and
it does it cleaner than your == test.

>>> so.. again for the above examples: puts "a is true in boolean
>>> context" if a puts "a is really a *true*" if a.true?
>> Why is this better than "if a == true"
> I think, its a personal taste.

That rather goes against (IMO) sensible program design, especially
if you're going to work with others.

> I like "a.nil?" more than "a == nil"
> same way, I like a.true? than a == true

> "We live in a free world"

Yes, we do. I don't think, however, that the Ruby world needs #true?
and #false?

well, we need to know first before using something.
If you are going to use #true?, you need to know what it does.
I am saying this, for your reply about work with others.
We really don't have Object#true? in ruby. If you see #true? in my code,
you got to look around my code to see what it does?
Same way, If I work with you, you might have some new
opinion/idea/concept that I am not familiar with. In that case, I will
have to do the same.

Mohammad

···

On Thu, 2004-11-11 at 16:15, Austin Ziegler wrote:

On Fri, 12 Nov 2004 05:41:50 +0900, Mohammad Khan <mkhan@lextranet.com> wrote:
> On Thu, 2004-11-11 at 14:50, Austin Ziegler wrote:

--

[mkhan@localhost local]$ make love
make: *** No rule to make target `love'. Stop.

63

Mohammad Khan wrote:

David,

I don't agree at this point, I would like to say

puts "a is neither nil, nor false, nor FALSE" if a
puts "a is true" if a == true

I consider nil, false and true as three different entity.
I don't need to show you irb screen output to illustrate it.

Thanks,
Mohammad

Correcting myself,
if it is (not nil and not false and not FALSE)
only remaining state is .. true or TRUE !!

I fail to see where the problem is. if *a* is not an instance of the NilClass or the FalseClass and *a* does not evaluate to nil or false, then it will always evaluate to true in a boolean expression. ie:

puts "a is neither nil && is not false && is not FALSE" if a

Where do you see that that will fail?

Also, if *a* is an instance of the TrueClass then it will equal true. ie;

puts "a is true" if a == true

if a is literally an instance of the TrueClass, but not if *a* is an instance of anything else.

Where are you seeing a problem?

Zach

64

Hi --

> David,
>
> I don't agree at this point, I would like to say
>
> puts "a is neither nil, nor false, nor FALSE" if a
> puts "a is true" if a == true

It comes back to the fact that the words 'true' and 'false' are used
in two different ways. My example:

  puts "a is true" if a

is using 'true' in the Boolean sense, which is actually the most
common role it plays in Ruby. I've seen very few tests to see whether
something is or is not the object true (TRUE). Usually the goal is to
test a condition, in which case "if a" works perfectly.

> I consider nil, false and true as three different entity.

They are. In addition, false and true are states. That's why we can
say things like:

   nil and false are false

which really means:

  the object nil and the object false both evaluate to Boolean false

(Otherwise, saying 'false is false' would be sort of pointless :slight_smile:

> I don't need to show you irb screen output to illustrate it.
>
> Thanks,
> Mohammad
>

Correcting myself,
if it is (not nil and not false and not FALSE)
only remaining state is .. true or TRUE !!

false and FALSE are the same object, as are true and TRUE; I was only
suggesting that using the constants might help clarify the object vs.
Boolean usage.

David

···

On Sat, 30 Oct 2004, Mohammad Khan wrote:

--
David A. Black
dblack@wobblini.net

65

If I am not mistaken this is probably something inherited from
smalltalk. Consider the code:

class False
  def false?
    yield
  end

  def true?
    nil
  end
end

# You can guess what True looks like...

def st_if(obj)
  yield if obj.true?
end

def st_unless(obj)
  yield if obj.false?
end

st_if True.new do
  puts "Hey!"
end

st_unless False.new do
  puts "There."
end

# results in:
# Hey!
# There.

···

On Sat, 30 Oct 2004 13:38:02 +0900, Austin Ziegler <halostatue@gmail.com> wrote:

On Sat, 30 Oct 2004 06:24:49 +0900, Mohammad Khan <mkhan@lextranet.com> wrote:

> I consider nil, false and true as three different entity.
> I don't need to show you irb screen output to illustrate it.

I'm not sure this is a good consideration. Coming from an SQL
background, it's easy to do, but I think that Matz has this right. A
nil value is something that's unset.

I still don't see a reason for #true? and #false?.

######

I quite like how smalltalk handled conditionals. It seems fundamental
rather than inventing a value to look for. It also fits duck typing
better. For example, you could make more than just nil and false
trigger an unless expression. This also gives a better view of why
there could be more than one false value in Ruby even though Ruby does
not follow this model completely.

:slight_smile:
  Brian Mitchell

66

Hi Ara,

You can extend Object

class Object
   def true?
       return self == true ? true : false
   end

   def false?
       return self == false? true : false
   end
end

···

On Mon, 2004-11-01 at 12:43, Ara.T.Howard@noaa.gov wrote:

On Tue, 2 Nov 2004, David A. Black wrote:

> #false? might be useful to avoid lengthier tests distinguishing among
> various permutations of falsehood. I can't see too many likely uses
> for #true?

i'd really like a #true?

   yaml = <<-txt
     options:
       verbose : true # or maybe 4
   txt

   config = YAML::load yaml

   options = config['options']

   if options['verbose'].true?
     @verbosity = 4
   else
     @verbosity = Integer options['verbose']
   end

now i use

   if TrueClass === options['verbose']
     @verbosity = 4
   else
     @verbosity = Integer options['verbose']
   end

which is kind of ugly. espcially where i care if it true OR false and end
doing

#
# foobar can be a bool or a number
#
   if [TrueClass, FalseClass].include? options['foobar'].class
     @foobar = options['foobar']
   else
     @foobar = Integer options['foobar']
   end

yuk!

--
Mohammad

cheers.

-a
--

> EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
> PHONE :: 303.497.6469
> When you do something, you should burn yourself completely, like a good
> bonfire, leaving no trace of yourself. --Shunryu Suzuki

67

Ara.T.Howard@noaa.gov said:

now i use

   if TrueClass === options['verbose']
     @verbosity = 4
   else
     @verbosity = Integer options['verbose']
   end

Hmmm ... why don't you use:

  if options['verbose'] == true
    ...

···

--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

68

Well that was just one example, of course I know about unless. I'm not
trying to get into a philosphically argument about unless vs. not v.s
false? The problem I have with unless is its starts looking weird if
its a multiway branch ie
if a
elsif b
elsif c
else

etc.

···

On Fri, 12 Nov 2004 04:56:17 +0900, Austin Ziegler <halostatue@gmail.com> wrote:

On Fri, 12 Nov 2004 04:47:27 +0900, Logan Capaldo > > > <logancapaldo@gmail.com> wrote:
> Well I have written true? and false? methods in the past. Forgetting
> the best implementation at the moment I use it because I find things
> like:
>
> if a.nil?.false?
> ....
> end
>
> more readable than
>
> if not a.nil?
> ....
> end

unless a.nil?
....
end

-austin
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

69

if a.notnil?
    ...
  end

:slight_smile:

···

On Friday, November 12, 2004, 6:56:17 AM, Austin wrote:

On Fri, 12 Nov 2004 04:47:27 +0900, Logan Capaldo > <logancapaldo@gmail.com> wrote:

Well I have written true? and false? methods in the past. Forgetting
the best implementation at the moment I use it because I find things
like:

if a.nil?.false?
   ....
end

more readable than

if not a.nil?
....
end

unless a.nil?
....
end

70

> No, I didn't. Not anything convincing, at any rate. It seemed to
> boil down to "I don't think that a == b is sufficiently OO", which
> is certainly not a good reason, IMO. Why do you not like "a ==
> true"?
Personal taste! May be I am fond of wired taste !!
Sorry for trying to share my wired taste with you.

Perhaps it is a matter of taste -- but is this sufficient reason to
want a change to the language? Again, I differentiate between your
proposal for #true? and #false? and the #iftrue mechanisms, as your
mechanism:

  if a.true?

doesn't really buy anything over

  if a == true

for tests of true-value. Wouldn't it be more OO to actually do:

  a.iftrue { things-to-do-if-true }.iffalse { things-to-do-if-false }

rather than simply what you've suggested?

> Yes, we do. I don't think, however, that the Ruby world needs #true?
> and #false?
well, we need to know first before using something.
If you are going to use #true?, you need to know what it does.
I am saying this, for your reply about work with others.
We really don't have Object#true? in ruby. If you see #true? in my code,
you got to look around my code to see what it does?
Same way, If I work with you, you might have some new
opinion/idea/concept that I am not familiar with. In that case, I will
have to do the same.

Mmmm. I donno. I don't think that you'd find anyone else using the
#true?/#false? mechanism you said. Most other folks would use
unfamiliar ideas, not unfamiliar and unintuitive syntax. To me, it is
*not* immediately obvious that #true? and #false? would test against
== true and == false.

-austin

···

On Fri, 12 Nov 2004 06:28:51 +0900, Mohammad Khan <mkhan@lextranet.com> wrote:

On Thu, 2004-11-11 at 16:15, Austin Ziegler wrote:
> On Fri, 12 Nov 2004 05:41:50 +0900, Mohammad Khan <mkhan@lextranet.com> > > > On Thu, 2004-11-11 at 14:50, Austin Ziegler wrote:

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

71

Hi There,

Style matters. Personal style matters too. In order
to make my code more readable (to those who don't
know my style) I put system wide changes to Ruby classes
in a file named "rcr.rb". This file implements "my little
darling ruby change requests".

So, if I were to implement true?/false? (which I am not
going to do), I would put the implementation in my rcr.ruby
file.

FWIW.

Yours,

    JeanHuguesRobert

PS: There is a copy of my rcr.rb at the end of this
msg.
EOM

···

At 06:28 12/11/2004 +0900, you wrote:

On Thu, 2004-11-11 at 16:15, Austin Ziegler wrote:

On Fri, 12 Nov 2004 05:41:50 +0900, Mohammad Khan <mkhan@lextranet.com> wrote:
> On Thu, 2004-11-11 at 14:50, Austin Ziegler wrote:
>> respectively. Thus, self == true and TrueClass === self (note the
>> inversion of parameters on the call to #===) are the same test.
>> You can more efficiently write what you want as:
>>
>> class Object
>> def true?
>> false
>> end
>>
>> def false?
>> false
>> end
>> end
> You might noticed from my previous posting, the reason to I want
> to have #true? and #false?

No, I didn't. Not anything convincing, at any rate. It seemed to
boil down to "I don't think that a == b is sufficiently OO", which
is certainly not a good reason, IMO. Why do you not like "a ==
true"?

Personal taste! May be I am fond of wired taste !!
Sorry for trying to share my wired taste with you.

> Example:
> a = true
> b = false
>
> using my 'class Object'
> a.true? -> true
> b.false? -> true
>
> using your 'class Object'
> a.true? -> false
> b.false? -> false
> which are wrong according to my proposed #true? and #false?

Not if you actually did what I said, which was *NOT* just adding
#true? and #false? to Object. Look again; it does what you want and
it does it cleaner than your == test.

>>> so.. again for the above examples: puts "a is true in boolean
>>> context" if a puts "a is really a *true*" if a.true?
>> Why is this better than "if a == true"
> I think, its a personal taste.

That rather goes against (IMO) sensible program design, especially
if you're going to work with others.

> I like "a.nil?" more than "a == nil"
> same way, I like a.true? than a == true

> "We live in a free world"

Yes, we do. I don't think, however, that the Ruby world needs #true?
and #false?

well, we need to know first before using something.
If you are going to use #true?, you need to know what it does.
I am saying this, for your reply about work with others.
We really don't have Object#true? in ruby. If you see #true? in my code,
you got to look around my code to see what it does?
Same way, If I work with you, you might have some new
opinion/idea/concept that I am not familiar with. In that case, I will
have to do the same.

Mohammad
--

[mkhan@localhost local]$ make love
make: *** No rule to make target `love'. Stop.

# rcr.rb
# Ruby Change Requests. Define changes to standard classes.
#
# 04/05/10, JHR, created from earlier work
# 04/05/11, JHR, class Binding methods + Proc##binding()
# 04/06/13, JHR, Binding.of_caller(), thanks to Florian Gross.
#
# (C) See at the end

# What you get when converting an Hash into an Array, see Hash##to_a().
# It is an array of [k,v].
class HashAsArray < Array

  def to_h()
    h = Hash.new()
    each do |(k,v)| h[k] = v end
    h
  end

end

# What you get when converting an Array into a Hash, see Array##to_h()
# It is a Hash with keys that are integer indexes (from 0 up to size of hash).
class ArrayAsHash < Hash

  def to_a()
    super().sort_by { |(k,v)| k }.collect { |(k,v)| v }
    # ToDo: There must be a faster solution to do that.
  end

end

# Have Hash.to_a() return an HashAsArray instead of an Array.
# Besides the class there are no other difference.
class Hash
  
  alias ruby_to_a to_a unless defined? ruby_to_a
  
  # Returns an array of [key,value] pairs.
  # Please note that h.to_a().to_h() == h for most purposes.
  def to_a()
    HashAsArray.new().replace( ruby_to_a())
  end
  
  # Returns self. Much like Array##to_a() does.
  def to_h()
    self
  end
  
  # Returns a new Hash updated with members from the other hash.
  def +( other )
    self.dup().update( other)
  end
  
  # Returns a new Hash updated with members from the other hash.
  def |( other )
    self.dup().update( other)
  end
  
end

# Have Array.to_h() return an ArrayAsHash.
# Please note that aa.to_h().to_a() == aa, which was the initial intend.
class Array
  def to_h()
    h = ArrayAsHash.new()
    each_index do |ii| h[ii] = self[ii] end
    return h
  end
  
end

class Symbol
  # I often interchange Strings and Symbol in my code.
  def intern()
    self
  end
  
end

class Continuation

  # Thanks to Florian Gross in ruby-talk ML msg 103312.
  def self.create( *args, &block )
    cc = nil;
    result = callcc { |c|
      cc = c;
      block.call( cc) if block and args.empty?
    }
    result ||= args
    return *[cc, *result]
  end
end

# By default class Binding has no methods at all !
class Binding

  # Evaluate a Ruby source code string in the binding context.
  def eval( str )
    Kernel.eval( str, self)
  end

  # Returns the value of self in the binding context.
  def self()
    eval( "self")
  end

  # Returns the local variables defined in the binding context.
  def local_variables()
    eval( "local_variables")
  end

  # Returns the Method that was active, if any, when the binding was created
  #def method() ...???...

  # Returns the Proc that was active, if any, when the binding was created
  #def proc() ... ??? ...

  # Returns the call stack, same format as Kernel##caller()
  def caller( skip = 0 )
    eval( "caller( #{skip})")
  end

  # Returns the value of some variable.
  def ( x )
    eval( x.to_s())
  end

  # Set the value of some lvalue.
  def =( l, v )
    eval( "proc {|v| #{l} = v").call( v)
  end

  # Returns the nature of something, nil if that thing is not defined.
  def defined?( x )
    eval( "defined? #{x}")
  end

  # Thanks to Florian Gross in ruby-talk ML msg 103312.
  # This method returns the binding of the method that called your
  # method. Don't use it when you're not inside a method.
  #
  # It's used like this:
  # def inc_counter
  # Binding.of_caller do |binding|
  # eval("counter += 1", binding)
  # end
  # end
  # counter = 0
  # 2.times { inc_counter }
  # counter # => 2
  #
  # You will have to put the whole rest of your method into the
  # block that you pass into this method. If you don't do this
  # an Exception will be raised. Because of the way that this is
  # implemented it has to be done this way.
  def self.of_caller( &block )
    old_critical = Thread.critical
    Thread.critical = true
    count = 0
    cc, result, error = Continuation.create( nil, nil)
    error.call if error
    tracer = lambda do |*args|
      type, context = args[0], args[4]
      if type == "return"
        count += 1
        # First this method and then calling one will return --
        # the trace event of the second event gets the context
        # of the method which called the method that called this
        # method.
        if count == 2
          # It would be nice if we could restore the trace_func
          # that was set before we swapped in our own one, but
          # this is impossible without overloading set_trace_func
          # in current Ruby.
          set_trace_func( nil)
          cc.call( eval( "binding", context), nil)
        end
      elsif type != "line"
        set_trace_func(nil)
        error_msg = "Binding.of_caller used in non-method context or " +
          "trailing statements of method using it aren't in the block."
        cc.call( nil, lambda { raise( ArgumentError, error_msg ) })
      end
    end
    unless result
      set_trace_func( tracer)
      return nil
    else
      Thread.critical = old_critical
      yield result
    end
  end

end

class Proc
  # Partial evaluation in Ruby. Return a new proc that invokes This
  # proc with some of the first parameters pre-initialized.
  # Sheme language inspired I think.
  # Thanks to Mauricio Fernández
  def curry( proc, *args )
    prod do | *a |
      proc.call( *(args + a))
    end
  end
  
  # lvalue able
  def =( *args )
    self[*args]
  end
  
  # Return the proc's binding
  def binding()
    eval( "binding", self)
  end
end

# ***** BEGIN LICENSE BLOCK *****
# Version: MPL 1.1
#
# The contents of this file are subject to the Mozilla Public License Version
# 1.1 (the "License"); you may not use this file except in compliance with
# the License. You may obtain a copy of the License at
# Mozilla Public Licence — Mozilla
#
# Software distributed under the License is distributed on an "AS IS" basis,
# WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
# for the specific language governing rights and limitations under the
# License.
#
# The Original Code is The Rever Reversible Reason.
#
# The Initial Developer of the Original Code is
# Jean-Hugues ROBERT (born dec 25 1965 in Nimes, France).
# Portions created by the Initial Developer are Copyright (C) 2002-2004
# the Initial Developer. All Rights Reserved.
#
# Contributor(s):
#
# ***** END LICENSE BLOCK *****

-------------------------------------------------------------------------
Web: http://hdl.handle.net/1030.37/1.1
Phone: +33 (0) 4 92 27 74 17

72

Hi Zach,

I already corrected myself.
Sorry for confusion.

···

On Fri, 2004-10-29 at 17:42, Zach Dennis wrote:

Mohammad Khan wrote:

>>David,
>>
>>I don't agree at this point, I would like to say
>>
>>puts "a is neither nil, nor false, nor FALSE" if a
>>puts "a is true" if a == true
>>
>>I consider nil, false and true as three different entity.
>>I don't need to show you irb screen output to illustrate it.
>>
>>Thanks,
>>Mohammad
>>
>>
>>
>
>Correcting myself,
>if it is (not nil and not false and not FALSE)
>only remaining state is .. true or TRUE !!
>
>
>
I fail to see where the problem is. if *a* is not an instance of the
NilClass or the FalseClass and *a* does not evaluate to nil or false,
then it will always evaluate to true in a boolean expression. ie:

puts "a is neither nil && is not false && is not FALSE" if a

Where do you see that that will fail?

Also, if *a* is an instance of the TrueClass then it will equal true. ie;

puts "a is true" if a == true

if a is literally an instance of the TrueClass, but not if *a* is an
instance of anything else.

Where are you seeing a problem?

Zach

--
Mohammad

73

That's interesting. Are you suggesting that `if` be a method?

T.

···

On Saturday 30 October 2004 01:58 am, Brian Mitchell wrote:

I quite like how smalltalk handled conditionals. It seems fundamental
rather than inventing a value to look for. It also fits duck typing
better. For example, you could make more than just nil and false
trigger an unless expression. This also gives a better view of why
there could be more than one false value in Ruby even though Ruby does
not follow this model completely.

74

You can extend Object

class Object
   def true?
       return self == true ? true : false
   end

   def false?
       return self == false? true : false
   end
end

There is a thread on suby-ruby about experimantation with this. Join in :slight_smile:

The actual implementation we are looking at avoids coversion or
comparison to bool but you get the same result. Its been interesting.

Brian Mitchell.

75

See, that's why I'm not getting this. I don't see the value of:

  if options['verbose'].true?

over

  if options['verbose'] == true

The reality is that the implementations of #true? and #false? provided
so far essentially hide that test, making this pure magic. I certainly
don't test against true and false values often enough to warrant these
methods, whereas I do consistently test against nil values.

-austin

···

On Tue, 2 Nov 2004 05:47:18 +0900, Jim Weirich <jim@weirichhouse.org> wrote:

Ara.T.Howard@noaa.gov said:
> now i use
>
> if TrueClass === options['verbose']
> @verbosity = 4
> else
> @verbosity = Integer options['verbose']
> end

Hmmm ... why don't you use:

  if options['verbose'] == true
    ...

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca
: as of this email, I have [ 5 ] Gmail invitations

76

Ruby allows all objects to eval as true values except the false and nil
instances. This allows one to easily check if an object was returned from a
call vs. nil

  md = /abc/.match(foo_string)
  if md
    #...
  end

So with what you're saying, we'd have to do:

  md = /abc/.match(foo_string)
  if ! md.nil?
    #...
  end

And to use #true?

  md = /abc/.match(foo_string)
  if md.true?
    #...
  end

Doesn't work, because what you're really asking is

  md = /abc/.match(foo_string)
  if (md != nil and md != false).true?
    #...
  end

So what does #true? gain you?

I suppose one could make a method out of the above if one really disliked
Ruby's built-in evaluation.

  class Object
    def is?
     (md != nil and md != false)
    end
  end

  md = /abc/.match(foo_string)
  if md.is?
    #...
  end

Personally, the only thing I really feel Ruby lacks in the arena is a
lower-level form of nil, i.e. nack, instance of NackClass. Sometimes nil is
useful in its own right as meaning emptiness, other times you really need to
pass through an unknown result but also might need to pass a flag indicating
something's not quite right. That's where nack is useful. It's kind of like a
managable error that can be propigated. Anyway, that's sort of O.T. I guess.

BTW Brian put this out,

  class Object
   def false?
nil
end

   def true?
yield
end
  end
  
Which is more intersting direction of inquiry, IMHO.

T.

···

On Monday 01 November 2004 03:34 pm, Mohammad Khan wrote:

You can extend Object

class Object
   def true?
       return self == true ? true : false
   end

   def false?
       return self == false? true : false
   end
end

77

In that case -- pun intended -- I use case statements, e.g.:

case
when a
when b
when c
else
end

-austin

···

On Fri, 12 Nov 2004 05:01:49 +0900, Logan Capaldo <logancapaldo@gmail.com> wrote:

Well that was just one example, of course I know about unless. I'm not
trying to get into a philosphically argument about unless vs. not v.s
false? The problem I have with unless is its starts looking weird if
its a multiway branch ie
if a
elsif b
elsif c
else

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

78

Gavin Sinclair wrote:

unless a.nil?
....
end

  if a.notnil?
    ...
  end

:slight_smile:

You put a smiley, but in all seriousness I've thought of this.
(Actually I'd use nonnil? or nnil?)

In fact, when I'm writing code that no one else will see,
<admission type="shameful"/> I sometime use methods like these:

   a1 =
   a2 = [1,2,3]
   s1 = ""
   s2 = "a string"
   h1 = {}
   h2 = {1=>2, 2=>4}

   a1.null? # true
   a1.nnull? # false
   a2.null? # false
   a2.nnull? # true

   s1.null? # true
   h1.null? # true

   # And so on...

See below, and let the flamefest begin.

Hal

   class Array
     def null?
       ! empty?
     end
   end

   class String
     def null?
       ! empty?
     end
   end

   class Hash
     def null?
       ! empty?
     end
   end

   class Fixnum
     def null?
       self == 0
     end
   end

   class File
     def null? # now a little fun
       size == 0
     end
   end

   # And now even more fun

   class Nil
     def null?
       true
     end
     def nnil? # for symmetry
       false
     end
   end

   # And the most fun of all, our beloved nnull?

   class Object
     def null
       false # until overridden
     end
     def nnull?
       ! null? # inherited by everyone
     end
   end

79

Hi There,

Style matters. Personal style matters too. In order
to make my code more readable (to those who don't
know my style) I put system wide changes to Ruby classes
in a file named "rcr.rb". This file implements "my little
darling ruby change requests".

So, if I were to implement true?/false? (which I am not
going to do), I would put the implementation in my rcr.ruby
file.

FWIW.

Yours,

    JeanHuguesRobert

PS: There is a copy of my rcr.rb at the end of this
msg.
EOM

Hi Jean,

I do the same. I fact I was doing it for a while.

Thanks,
Mohammad

···

On Fri, 2004-11-12 at 08:02, Jean-Hugues ROBERT wrote:

At 06:28 12/11/2004 +0900, you wrote:
>On Thu, 2004-11-11 at 16:15, Austin Ziegler wrote:
>> On Fri, 12 Nov 2004 05:41:50 +0900, Mohammad Khan <mkhan@lextranet.com> wrote:
>> > On Thu, 2004-11-11 at 14:50, Austin Ziegler wrote:
>> >> respectively. Thus, self == true and TrueClass === self (note the
>> >> inversion of parameters on the call to #===) are the same test.
>> >> You can more efficiently write what you want as:
>> >>
>> >> class Object
>> >> def true?
>> >> false
>> >> end
>> >>
>> >> def false?
>> >> false
>> >> end
>> >> end
>> > You might noticed from my previous posting, the reason to I want
>> > to have #true? and #false?
>>
>> No, I didn't. Not anything convincing, at any rate. It seemed to
>> boil down to "I don't think that a == b is sufficiently OO", which
>> is certainly not a good reason, IMO. Why do you not like "a ==
>> true"?
>
>Personal taste! May be I am fond of wired taste !!
>Sorry for trying to share my wired taste with you.
>
>>
>> > Example:
>> > a = true
>> > b = false
>> >
>> > using my 'class Object'
>> > a.true? -> true
>> > b.false? -> true
>> >
>> > using your 'class Object'
>> > a.true? -> false
>> > b.false? -> false
>> > which are wrong according to my proposed #true? and #false?
>>
>> Not if you actually did what I said, which was *NOT* just adding
>> #true? and #false? to Object. Look again; it does what you want and
>> it does it cleaner than your == test.
>>
>> >>> so.. again for the above examples: puts "a is true in boolean
>> >>> context" if a puts "a is really a *true*" if a.true?
>> >> Why is this better than "if a == true"
>> > I think, its a personal taste.
>>
>> That rather goes against (IMO) sensible program design, especially
>> if you're going to work with others.
>>
>> > I like "a.nil?" more than "a == nil"
>> > same way, I like a.true? than a == true
>>
>> > "We live in a free world"
>>
>> Yes, we do. I don't think, however, that the Ruby world needs #true?
>> and #false?
>
>well, we need to know first before using something.
>If you are going to use #true?, you need to know what it does.
>I am saying this, for your reply about work with others.
>We really don't have Object#true? in ruby. If you see #true? in my code,
>you got to look around my code to see what it does?
>Same way, If I work with you, you might have some new
>opinion/idea/concept that I am not familiar with. In that case, I will
>have to do the same.
>
>
>Mohammad
>--
>
>[mkhan@localhost local]$ make love
>make: *** No rule to make target `love'. Stop.

# rcr.rb
# Ruby Change Requests. Define changes to standard classes.
#
# 04/05/10, JHR, created from earlier work
# 04/05/11, JHR, class Binding methods + Proc##binding()
# 04/06/13, JHR, Binding.of_caller(), thanks to Florian Gross.
#
# (C) See at the end

# What you get when converting an Hash into an Array, see Hash##to_a().
# It is an array of [k,v].
class HashAsArray < Array

  def to_h()
    h = Hash.new()
    each do |(k,v)| h[k] = v end
    h
  end

end

# What you get when converting an Array into a Hash, see Array##to_h()
# It is a Hash with keys that are integer indexes (from 0 up to size of hash).
class ArrayAsHash < Hash

  def to_a()
    super().sort_by { |(k,v)| k }.collect { |(k,v)| v }
    # ToDo: There must be a faster solution to do that.
  end

end

# Have Hash.to_a() return an HashAsArray instead of an Array.
# Besides the class there are no other difference.
class Hash
  
  alias ruby_to_a to_a unless defined? ruby_to_a
  
  # Returns an array of [key,value] pairs.
  # Please note that h.to_a().to_h() == h for most purposes.
  def to_a()
    HashAsArray.new().replace( ruby_to_a())
  end
  
  # Returns self. Much like Array##to_a() does.
  def to_h()
    self
  end
  
  # Returns a new Hash updated with members from the other hash.
  def +( other )
    self.dup().update( other)
  end
  
  # Returns a new Hash updated with members from the other hash.
  def |( other )
    self.dup().update( other)
  end
  
end

# Have Array.to_h() return an ArrayAsHash.
# Please note that aa.to_h().to_a() == aa, which was the initial intend.
class Array
  def to_h()
    h = ArrayAsHash.new()
    each_index do |ii| h[ii] = self[ii] end
    return h
  end
  
end

class Symbol
  # I often interchange Strings and Symbol in my code.
  def intern()
    self
  end
  
end

class Continuation

  # Thanks to Florian Gross in ruby-talk ML msg 103312.
  def self.create( *args, &block )
    cc = nil;
    result = callcc { |c|
      cc = c;
      block.call( cc) if block and args.empty?
    }
    result ||= args
    return *[cc, *result]
  end
end

# By default class Binding has no methods at all !
class Binding

  # Evaluate a Ruby source code string in the binding context.
  def eval( str )
    Kernel.eval( str, self)
  end

  # Returns the value of self in the binding context.
  def self()
    eval( "self")
  end

  # Returns the local variables defined in the binding context.
  def local_variables()
    eval( "local_variables")
  end

  # Returns the Method that was active, if any, when the binding was created
  #def method() ...???...

  # Returns the Proc that was active, if any, when the binding was created
  #def proc() ... ??? ...

  # Returns the call stack, same format as Kernel##caller()
  def caller( skip = 0 )
    eval( "caller( #{skip})")
  end

  # Returns the value of some variable.
  def ( x )
    eval( x.to_s())
  end

  # Set the value of some lvalue.
  def =( l, v )
    eval( "proc {|v| #{l} = v").call( v)
  end

  # Returns the nature of something, nil if that thing is not defined.
  def defined?( x )
    eval( "defined? #{x}")
  end

  # Thanks to Florian Gross in ruby-talk ML msg 103312.
  # This method returns the binding of the method that called your
  # method. Don't use it when you're not inside a method.
  #
  # It's used like this:
  # def inc_counter
  # Binding.of_caller do |binding|
  # eval("counter += 1", binding)
  # end
  # end
  # counter = 0
  # 2.times { inc_counter }
  # counter # => 2
  #
  # You will have to put the whole rest of your method into the
  # block that you pass into this method. If you don't do this
  # an Exception will be raised. Because of the way that this is
  # implemented it has to be done this way.
  def self.of_caller( &block )
    old_critical = Thread.critical
    Thread.critical = true
    count = 0
    cc, result, error = Continuation.create( nil, nil)
    error.call if error
    tracer = lambda do |*args|
      type, context = args[0], args[4]
      if type == "return"
        count += 1
        # First this method and then calling one will return --
        # the trace event of the second event gets the context
        # of the method which called the method that called this
        # method.
        if count == 2
          # It would be nice if we could restore the trace_func
          # that was set before we swapped in our own one, but
          # this is impossible without overloading set_trace_func
          # in current Ruby.
          set_trace_func( nil)
          cc.call( eval( "binding", context), nil)
        end
      elsif type != "line"
        set_trace_func(nil)
        error_msg = "Binding.of_caller used in non-method context or " +
          "trailing statements of method using it aren't in the block."
        cc.call( nil, lambda { raise( ArgumentError, error_msg ) })
      end
    end
    unless result
      set_trace_func( tracer)
      return nil
    else
      Thread.critical = old_critical
      yield result
    end
  end

end

class Proc
  # Partial evaluation in Ruby. Return a new proc that invokes This
  # proc with some of the first parameters pre-initialized.
  # Sheme language inspired I think.
  # Thanks to Mauricio Fernández
  def curry( proc, *args )
    prod do | *a |
      proc.call( *(args + a))
    end
  end
  
  # lvalue able
  def =( *args )
    self[*args]
  end
  
  # Return the proc's binding
  def binding()
    eval( "binding", self)
  end
end

# ***** BEGIN LICENSE BLOCK *****
# Version: MPL 1.1
#
# The contents of this file are subject to the Mozilla Public License Version
# 1.1 (the "License"); you may not use this file except in compliance with
# the License. You may obtain a copy of the License at
# Mozilla Public Licence — Mozilla
#
# Software distributed under the License is distributed on an "AS IS" basis,
# WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
# for the specific language governing rights and limitations under the
# License.
#
# The Original Code is The Rever Reversible Reason.
#
# The Initial Developer of the Original Code is
# Jean-Hugues ROBERT (born dec 25 1965 in Nimes, France).
# Portions created by the Initial Developer are Copyright (C) 2002-2004
# the Initial Developer. All Rights Reserved.
#
# Contributor(s):
#
# ***** END LICENSE BLOCK *****

-------------------------------------------------------------------------
Web: http://hdl.handle.net/1030.37/1.1
Phone: +33 (0) 4 92 27 74 17

--

[mkhan@localhost local]$ rm -Rf /bin/laden

80

> > No, I didn't. Not anything convincing, at any rate. It seemed to
> > boil down to "I don't think that a == b is sufficiently OO", which
> > is certainly not a good reason, IMO. Why do you not like "a ==
> > true"?
> Personal taste! May be I am fond of wired taste !!
> Sorry for trying to share my wired taste with you.

Perhaps it is a matter of taste -- but is this sufficient reason to
want a change to the language?

Answer is Yes.
If you find something good to you, you will want to share it others.
After share it with others, you might learn that your idea it not as
good as it were to you.

Well, I have learned many of us did not like this #true? and #false?
idea. But I still like it.

Again, I differentiate between your
proposal for #true? and #false? and the #iftrue mechanisms, as your
mechanism:

  if a.true?

doesn't really buy anything over

  if a == true

for tests of true-value. Wouldn't it be more OO to actually do:

  a.iftrue { things-to-do-if-true }.iffalse { things-to-do-if-false }

rather than simply what you've suggested?

> > Yes, we do. I don't think, however, that the Ruby world needs #true?
> > and #false?
> well, we need to know first before using something.
> If you are going to use #true?, you need to know what it does.
> I am saying this, for your reply about work with others.
> We really don't have Object#true? in ruby. If you see #true? in my code,
> you got to look around my code to see what it does?
> Same way, If I work with you, you might have some new
> opinion/idea/concept that I am not familiar with. In that case, I will
> have to do the same.

Mmmm. I donno. I don't think that you'd find anyone else using the
#true?/#false? mechanism you said. Most other folks would use
unfamiliar ideas, not unfamiliar and unintuitive syntax. To me, it is
*not* immediately obvious that #true? and #false? would test against
== true and == false.

-austin

Sometimes new things are unfamiliar, even existing thing can be
unfamiliar. Unfamiliar doesn't mean wrong. There is no way around other
than learn to be familiar with them.
Here is an example,
In ruby there have many methods that names end with '!' like, collect!,
compact!. I was so used to that '!' means its return the object after
'affect' and without '!' return the part of the object that was
affected. I hope, you guys understood me. English is not my primary
language.
I wrote a script by using Array#delete. I and one of co-worker were
working together. When he saw my code, he said it should be #delete!.
BTW, we are coding in Ruby for about two years. when I wrote that line,
I also wrote '#delete!' ! But after ran my script first time I got to
look at my 'Programming Ruby' book.

Mohammad

···

On Thu, 2004-11-11 at 21:54, Austin Ziegler wrote:

On Fri, 12 Nov 2004 06:28:51 +0900, Mohammad Khan <mkhan@lextranet.com> wrote:
> On Thu, 2004-11-11 at 16:15, Austin Ziegler wrote:
> > On Fri, 12 Nov 2004 05:41:50 +0900, Mohammad Khan <mkhan@lextranet.com> > > > On Thu, 2004-11-11 at 14:50, Austin Ziegler wrote:

--

[mkhan@localhost local]$ rm -Rf /bin/laden