Ruby wish-list

Ruby
41

On Nov 15, 2007 5:48 PM, Suraj K. [email protected] wrote:

workaround obsolete:
Thanks for your consideration.
Here you go (wouldn’t use it myself though):

class Module

get a unique alias

method_name = ‘attr_accessor#{rand(123456789)}__#{Time.now.to_i}’
alias_method method_name, :attr_accessor

define_method :attr_accessor do |name|
name = name.to_s
if name[-1] == ??
sname = name[0…-2]
attr_writer sname
define_method “#{name}” do
instance_variable_get “@#{sname}”
end
else
send(method_name, name)
end
end
end

class Foo
attr_accessor :readable?
attr_accessor :bar
end

f = Foo.new
f.readable? # => nil
f.readable = 99 # => 99
f.readable? # => 99

f.bar = 42 # => 42

Regards,
Sean

42

Todd B. wrote:

No convention in Ruby, but in Ruby programmers.
Right. And in a TIMTOWTDI language is can amount to the same thing.

with it, but then when you want to do something with it, you start
setting down ground rules in order to play well with others.

Exactly. Yes, there are exceptions, and yes that can be handy, but
(culturally speaking) treating foo? as an attribute accessor is probably
a mistake because you may be relying on a quirk of implementation.

Since every method could be used as a boolean value, the use of ‘?’
should be reserved to expressed a particular meaning, i.e., all this
method assures you is that you’ll get a return value than can be
interpreted as true or false, and is not meant to be an object
accessors.

defined?(a) # => nil
a = 1
defined?(a) # => “local-variable”

By the way, you really meant true instead of TrueClass right?

Well, that’s kind of just semantics. James may have meant an instance
of TrueClass, but didn’t word it that way.

Yes, thank you. I meant not simply true (i.e., something that is not
nil), but “only” true (and not some particular object you are relying on
to have a secondary value).

–
James B.

“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)
43

James B. wrote:

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. :slight_smile:

44

On Nov 15, 2007 10:29 PM, Suraj K. [email protected] wrote:

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. :slight_smile:

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

45

Suraj K. wrote:

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. :slight_smile:

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 B.

“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)
46

On Nov 16, 2007 3:04 AM, Todd B. [email protected] wrote:

And that’s the key point here: context.
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

47

James B. wrote:

Suraj K. wrote:

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. :slight_smile:

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.

48

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)

49

Suraj K. wrote:

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

50

On Nov 16, 2007 9:26 AM, Roger P. [email protected] wrote:

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

51

On Nov 29, 9:28 pm, Roger P. [email protected] wrote:

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 :slight_smile:
-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.

52

On Fri, 30 Nov 2007 12:06:18 +0900, Trans [email protected] wrote:

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”]

53

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 :slight_smile:
-Roger

54

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

55

On Nov 29, 10:16 pm, “Paul McMahon” [email protected] wrote:

"just another instance var #{k} = #{v}"

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! :wink:

T.

56

On Jan 9, 2008 2:37 PM, Roger P. [email protected] wrote:

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

57

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
:slight_smile:

58

2008/1/21, Roger P. [email protected]:

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

59

Robert K. wrote:

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!

60

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 :slight_smile:
Take care.
-Roger