ruby wish-list

[Suraj Kurapati]

you'll get a return value than can be interpreted as true or false

^^^^^^^^^^^

Bingo! I don't want to restrict the return values of question-mark
methods to only true and false because I see nothing special about
'true' and 'false'. In my mind, they are just objects that just happen
to have some useful equivalents when evaluated in a boolean context.
And that's the key point here: context.

Who cares what the type/class of an object really is, so long as the
object can be *interpreted* in a meaningful way in the particular usage
context? Sounds like the fundamental concept of duck typing to me.

 

[James Britt]

^^^^^^^^^^^

Bingo! I don't want to restrict the return values of question-mark
methods to only true and false because I see nothing special about
'true' and 'false'. In my mind, they are just objects that just happen
to have some useful equivalents when evaluated in a boolean context.
And that's the key point here: context.

Who cares what the type/class of an object really is, so long as the
object can be *interpreted* in a meaningful way in the particular usage
context? Sounds like the fundamental concept of duck typing to me.

This is what I'm warning against:

# First release of some library API
def account?
@account
end

# In some naive end-user's code:
@a.cancel if @a = foo.account?

# Later release of library API, after some internal changes
def account?
parent_has_account_and_is_active?
end


Now, what happens to the end user's code?

'account?' is still meaningful as a true/false indicator method; code
(mistakenly) relying on a more meaningful return object may get a
surprise one day.

I'm arguing that methods that end in "?" should be designed and used as
answers to true/false or yes/no questions. That they can return an
arbitrary non-nil object to indicate 'true' is convenient, but I'm
skeptical of the value of "?" methods being used as both boolean
indicators *and* object accessors.

Its a matter of hiding implementation details, and self-documenting code.

Now, should one do this?

def account?
@account ? true : false
end


Well, maybe; it might keep end-users from trying to be too clever.

But I don't think it should be baked into the language.


--
James Britt

"Programs must be written for people to read, and only incidentally
for machines to execute."
- H. Abelson and G. Sussman
(in "The Structure and Interpretation of Computer Programs)

 

[Todd Benson]

^^^^^^^^^^^

Bingo! I don't want to restrict the return values of question-mark
methods to only true and false because I see nothing special about
'true' and 'false'. In my mind, they are just objects that just happen
to have some useful equivalents when evaluated in a boolean context.
And that's the key point here: context.

Who cares what the type/class of an object really is, so long as the
object can be *interpreted* in a meaningful way in the particular usage
context? Sounds like the fundamental concept of duck typing to me.

I'm out of my league here (again), but I should mention that even
though we enjoy/love the flexibility of the Ruby language, that
freeness comes with a modicum of responsibility.

If you start turning ? into a Fixnum (i.e. that's what the #whatever?
method returns), you've started to turn a duck in to a goose (or cat,
dog, whatever). Hey, whatever floats your boat...

I can't think of one single reason for a variable/accessor to have a ?
on the end of it.

Todd

 

[Todd Benson]

I'm out of my league here (again), but I should mention that even
though we enjoy/love the flexibility of the Ruby language, that
freeness comes with a modicum of responsibility.

If you start turning ? into a Fixnum (i.e. that's what the #whatever?
method returns), you've started to turn a duck in to a goose (or cat,
dog, whatever). Hey, whatever floats your boat...

I can't think of one single reason for a variable/accessor to have a ?
on the end of it.

I'll add more noise and clarify a little. I think James made a very
succinct point. Useful at times, yes; should be baked into the
language, umm, probably not. The ? trailing symbol can be seen
several different ways. I tend to agree with others that it should
give me something I can count on (TrueClass or FalseClass). If people
want to mess with that ... I can adapt; no big deal.

But, if you do, you kind of open pandora's box, because then we might
have to start questioning every object before we can ask it to do
something (be it true, false, nil, fixnum, string, etc). I'm willing
to do that, but I don't think that is a healthy way to program.

Todd

 

[Suraj Kurapati]

This is what I'm warning against:

# First release of some library API
def account?
@account
end

# In some naive end-user's code:
@a.cancel if @a = foo.account?

Naive indeed. Why would anybody use a question mark method in that way?
They are only meant to be used in boolean contexts.

I think the convention lies not in what the return value of a
question-mark method is, but in what way the return value is used:

if foo.account?
foo.account.cancel
end

# Later release of library API, after some internal changes
def account?
parent_has_account_and_is_active?
end


Now, what happens to the end user's code?

'account?' is still meaningful as a true/false indicator method; code
(mistakenly) relying on a more meaningful return object may get a
surprise one day.

Exactly. That was foolishness on the user's part.

I'm arguing that methods that end in "?" should be designed and used as
answers to true/false or yes/no questions. That they can return an
arbitrary non-nil object to indicate 'true' is convenient, but I'm
skeptical of the value of "?" methods being used as both boolean
indicators *and* object accessors.

Ah, now I understand your point. I never considered them being used as
object accessors because you would never know it was an object accessor
just by looking at the method name.

foo.account? does not appear like an attr_reader because of the
question-mark.

Its a matter of hiding implementation details, and self-documenting
code.

Now, should one do this?

def account?
@account ? true : false
end

Yuck! No way. This is what I was arguing against. No forcing of
return value to be true/false only.

Well, maybe; it might keep end-users from trying to be too clever.

I don't see how they can be clever *unless* they look at the underlying
implementation of your classes. When I see the name of a question-mark
method, I think "this method answers a yes/no question". There is no
way I would think otherwise unless I was given insider information about
the method's implementation.

But I don't think it should be baked into the language.

I think the "accessor" in attr_accessor might have mislead you guys
about this whole question-mark argument.

 

[Suraj Kurapati]

I think the convention lies not in what the return value of a
question-mark method is, but in what way the return value is used:

if foo.account?
foo.account.cancel
end

Whoops, that is a bad example. Try this one instead:

if foo.account?
# do something...
end

 

[Roger Pack]

I'm arguing that methods that end in "?" should be designed and used as

answers to true/false or yes/no questions. That they can return an
arbitrary non-nil object to indicate 'true' is convenient, but I'm
skeptical of the value of "?" methods being used as both boolean
indicators *and* object accessors.

Its a matter of hiding implementation details, and self-documenting
code.

Yeah--I'd be in favor that anything that ends in ? be something that can
be evaluated as nil/non-nil (and hence having a 'boolean-only' variable
that ends with ? would be the same effect, hence my wishing that
variables could end in ?. Then you wouldn't have to create wrappers for
them. My $0.02)

 

[Todd Benson]

Yeah--I'd be in favor that anything that ends in ? be something that can
be evaluated as nil/non-nil (and hence having a 'boolean-only' variable
that ends with ? would be the same effect, hence my wishing that
variables could end in ?. Then you wouldn't have to create wrappers for
them. My $0.02)

Like I said before, I can see the utility of such a thing, but the ?
symbol is sort of special. In other words, I don't see it useful to
add functionality to Ruby that makes the ? symbol equal to whether a
variable/accessor exists or not. It doesn't fit for me. Maybe
another symbol/word?

Todd

 

[Roger Pack]

My latest wish for the wishing tree...
that if you used a variable
@not_yet_defined
that it would throw an error. I think it would help avoid a few bugs.
My daily $.02 for free
-Roger

 

[Trans]

My latest wish for the wishing tree...
that if you used a variable
@not_yet_defined
that it would throw an error. I think it would help avoid a few bugs.
My daily $.02 for free
-Roger

mmm... probably too few to be too worried about it though ?

i have one for you, since were throw'n them out. i wish "@" was a
hash.

x = "a"
@[x] = 1

@a #=> 1

@.each do |k,v|
"just another instance var #{k} = #{v}"
end

#=> just another instance var a = 1

T.

 

[Paul McMahon]

i have one for you, since were throw'n them out. i wish "@" was a
hash.

x =3D "a"
@[x] =3D 1

@a #=3D> 1

@.each do |k,v|
"just another instance var #{k} =3D #{v}"
end

#=3D> just another instance var a =3D 1

T.

You can already do that
irb(main):001:0> @a =3D 1
=3D> 1
irb(main):002:0> instance_variables.each do |k|
irb(main):003:1* v =3D instance_variable_get(k)
irb(main):004:1> puts "just another instance var #{k} =3D #{v}"
irb(main):005:1> end
just another instance var @a =3D 1
=3D> ["@a"]

 

[Trans]

i have one for you, since were throw'n them out. i wish "@" was a
hash.

x = "a"
@[x] = 1

@a #=> 1

@.each do |k,v|
"just another instance var #{k} = #{v}"
end

#=> just another instance var a = 1

T.

You can already do that
irb(main):001:0> @a = 1
=> 1
irb(main):002:0> instance_variables.each do |k|
irb(main):003:1* v = instance_variable_get(k)
irb(main):004:1> puts "just another instance var #{k} = #{v}"
irb(main):005:1> end
just another instance var @a = 1
=> ["@a"]

Really? That's amazing!

T.

 

[Roger Pack]

My biggest wish list currently is...I wish I didn't have to use # within
strings--just braces. That would ruby-like in elegance, in my opinion,
and (I think) parsable.
Thoughts?
-Roger

 

[Alex LeDonne]

My biggest wish list currently is...I wish I didn't have to use # within
strings--just braces. That would ruby-like in elegance, in my opinion,
and (I think) parsable.
Thoughts?
-Roger

I think bare braces are too common in strings to force backslashing
them all over the place, whereas the character sequence #{ almost
never shows up. Plus, it would be a mess every time you wanted to,
say, eval() a string that includes a block.

-A

 

[Roger Pack]

I think bare braces are too common in strings to force backslashing
them all over the place, whereas the character sequence #{ almost
never shows up. Plus, it would be a mess every time you wanted to,
say, eval() a string that includes a block.

I'd use them (well, I never use eval maybe that's why)

Next wish for the magic lamp:
a command that does something like
module X
CONSTANT = '3'
def class_function
end
end

class Y
extend_and_include_constants X # this one
end

 

[Robert Klemme]

Next wish for the magic lamp:
a command that does something like
module X
CONSTANT = '3'
def class_function
end
end

class Y
extend_and_include_constants X # this one
end

That's not too hard. All the ingredients are there already:

irb(main):001:0> class Module
irb(main):002:1> def your_extend(mod)
irb(main):003:2> extend mod
irb(main):004:2> mod.constants.each do |co|
irb(main):005:3* const_set(co, mod.const_get(co))
irb(main):006:3> end
irb(main):007:2> end
irb(main):008:1> end
=> nil
irb(main):009:0> module X
irb(main):010:1> Foo = 2
irb(main):011:1> def mm; 1; end
irb(main):012:1> end
=> nil
irb(main):013:0> class Y
irb(main):014:1> your_extend X
irb(main):015:1> end
=> ["Foo"]
irb(main):016:0> Y.mm
=> 1
irb(main):017:0> Y::Foo
=> 2

Cheers

robert

 

[Roger Pack]

irb(main):001:0> class Module
irb(main):002:1> def your_extend(mod)
irb(main):003:2> extend mod
irb(main):004:2> mod.constants.each do |co|
irb(main):005:3* const_set(co, mod.const_get(co))
irb(main):006:3> end
irb(main):007:2> end
irb(main):008:1> end
=> nil

wow
Thanks!

 

[Roger Pack]

I know this is controversial, but I wish that if you did
string_1 + object_2 (or any object) that it would just call .to_s on
object_2 (instead of having to write it explicitly). I hate having to
write extra .to_s's (even if it avoids ambiguity). That's just me, but
hey
Take care.
-Roger

 

[Chad Perrin]

I know this is controversial, but I wish that if you did
string_1 + object_2 (or any object) that it would just call .to_s on
object_2 (instead of having to write it explicitly). I hate having to
write extra .to_s's (even if it avoids ambiguity). That's just me, but
hey

irb

irb(main):001:0> obj = Object.new
=> #<Object:0x8064048>
irb(main):002:0> puts obj
#<Object:0x8064048>
=> nil
irb(main):003:0> puts obj.to_s
#<Object:0x8064048>
=> nil

Seems like it already does what you want. What am I missing?

 

[Roger Pack]

referent to
'a' + 3
which, if I had my wish, would automatically be 'a' + 3.to_s