[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

ruby wish-list

Roger Pack

10/15/2007 2:23:00 PM

My personal ruby wish-list (for any feedback):


1) the ability to rescue arrays (or some way to rescue multiple classes
without pain), like this:

all_socket_interrupts_array = [SocketError, Errno::EHOSTUNREACH,
Errno::ENETUNREACH]

begin
# stuff
rescue all_socket_interrupts # non ugly, yet precise!

end

2) a GC that is 'user-definable' (run after this definable threshold,
this often), and (asidedbly), a GC that can run in its own (native)
thread so it doesn't pause execution of normal threads.

3) an ensure block that's uninterruptible, a la:

begin
# do stuff
rescue
# rescue stuff
ensure_uninterruptible # (or call it ensure_critical)
# do stuff which is guaranteed to get run, and not interrupted.
end

4) the optional ability to have it display the whole backtrace on
uncaught exceptions (and also for all existing threads).

Guess that's it :)

Any thoughts?
Thanks.
-Roger
--
Posted via http://www.ruby-....
117 Answers

Alex Young

10/15/2007 2:32:00 PM

0

Roger Pack wrote:
> My personal ruby wish-list (for any feedback):
>
>
> 1) the ability to rescue arrays (or some way to rescue multiple classes
> without pain), like this:
>
> all_socket_interrupts_array = [SocketError, Errno::EHOSTUNREACH,
> Errno::ENETUNREACH]
>
> begin
> # stuff
> rescue all_socket_interrupts # non ugly, yet precise!
rescue *all_socket_interrupts_array => e

Should work, I think. At least, it appears to under my brief tests...

--
Alex

Roger Pack

10/15/2007 2:46:00 PM

0

Works great thanks Alex!

> > begin
> > # stuff
> > rescue all_socket_interrupts # non ugly, yet precise!
>
> rescue *all_socket_interrupts_array => e
>
> Should work, I think. At least, it appears to under my brief tests...
>
> --
> Alex

Rick DeNatale

11/7/2007 3:26:00 PM

0

On 11/6/07, Roger Pack <rogerpack2005@gmail.com> wrote:
> > Take care.
> > -Roger
>
> I wish... that Range.to_a wouldn't become obselete, as it seems quite useful
> in rails!

Assuming you mean Range#to_a (i.e. an instance rather that class
method) I don't think it's becoming obsolete.

There was talk some time ago when Matz changed 1.9 to use to_splat
instead of to_a that ranges wouldn't be splatted, e.g.

a = *(1..3)

In 1.8 this sets a to [1,2,3] whereas at one time in 1.9 it was to
have set it to [(1..3)].

But testing with a fairly recent irb1.9 this seems to be one of the
changes which has been backed out of 1.9.


--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denh...

Rick DeNatale

11/11/2007 3:11:00 PM

0

On Nov 11, 2007 1:13 AM, Roger Pack <rogerpack2005@gmail.com> wrote:
> >> I wish... that Range.to_a wouldn't become obselete, as it seems quite useful
> >> in rails!
> >
> > Assuming you mean Range#to_a (i.e. an instance rather that class
> > method) I don't think it's becoming obsolete.
>
> It throws warnings as deprecated, for some reason.

I don't think so:

shadowfax:~/Documents/terralien/dltsolutions/enrollnow rick$ ruby1.9 -v
ruby 1.9.0 (2007-10-25 patchlevel 0) [i686-darwin8.10.2]
shadowfax:~/Documents/terralien/dltsolutions/enrollnow rick$ ruby1.9
-we '(1..3).to_a'
shadowfax:~/Documents/terralien/dltsolutions/enrollnow rick$ ruby1.9
-we 'p (1..3).to_a'
-e:1: warning: (...) interpreted as grouped expression
[1, 2, 3]
shadowfax:~/Documents/terralien/dltsolutions/enrollnow rick$ ruby1.9
-we 'p((1..3).to_a)'
[1, 2, 3]



--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denh...

Todd Benson

11/15/2007 9:19:00 PM

0

On Nov 15, 2007 11:48 AM, Suraj Kurapati <snk@gna.org> wrote:
> Marc Heiler wrote:
> > (By the way, an accessor_read that can query variables with ? on the end
> > would be nice in std ruby too... I am not complaining at all, ruby is so
> > flexible, I already use this for my code and i love it, like @file.readable?
> > that queries a "special" reader accessor... i think it reads nicer than
> > @file.readable but this is just my opinion)
>
> Do you mean that attr_accessor treats symbols with a question mark
> differently by creating a "symbol_without_question=" writer method and a
> "symbol_with_question" reader method? For example:
>
> class Foo
> attr_acessor :readable? # defines Foo#readable= and Foo#readable?
> end
>
> f = Foo.new
> f.readable? #=> nil
> f.readable = 99
> f.readable? #=> 99
>
> This would be very useful, because it would make the following
> workaround obsolete:
>
> class Foo
> attr_writer :readable # only defines Foo#readable=
>
> def readable?
> @readable
> end
> end
>
> Oh wishing star, here is another wish for you! :-)
> Thanks for your consideration.

I would think that you would want to maintain the ? behavior across
the board. In other words, it should return TrueClass or FalseClass
objects.

Todd

James Britt

11/15/2007 10:31:00 PM

0

Suraj Kurapati wrote:
> Todd Benson wrote:
>> I would think that you would want to maintain the ? behavior across
>> the board. In other words, it should return TrueClass or FalseClass
>> objects.
>
> Why? In Ruby, anything that is neither nil nor false is the same as
> true... I cannot express how many thousands of times this convention
> has simplified my code and eased my life! Furthermore, like method
> aliases, this convention falls in line with Ruby's TIMTOWDI philosophy.
>
> So, forcing question-mark methods to return only 'true' and 'false'
> feels far too restrictive and seems to follow a
> there's-only-one-way-to-do-it philosophy IMHO.

Forcing would be bad, but there is the convention that foo? returns true
vs. false, not something vs. nil.

If a foo? method happens to be returning something other than TrueClass,
and you start depending on that quirk, you run the risk that a later
version of that method returns some other non-nil/non-false object.

It's similar to the use of foo!. You don't *have* to use the bang only
when your method is doing something destructive, but you'd be foolish
not to follow the conventions.



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

Rick DeNatale

11/15/2007 11:28:00 PM

0

On Nov 15, 2007 5:30 PM, James Britt <james.britt@gmail.com> wrote:
>
> Suraj Kurapati wrote:

> > So, forcing question-mark methods to return only 'true' and 'false'
> > feels far too restrictive and seems to follow a
> > there's-only-one-way-to-do-it philosophy IMHO.
>
> Forcing would be bad, but there is the convention that foo? returns true
> vs. false, not something vs. nil.

There is no such convention in Ruby.

> If a foo? method happens to be returning something other than TrueClass,
> and you start depending on that quirk, you run the risk that a later
> version of that method returns some other non-nil/non-false object.

There ARE cases in the ruby language where a x? returns something
other than true or false

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

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

The real danger is that you start testing 'truth' with expressions
like x == true or x == false. As long as you don't do that and simply
use the value in conditional expressions like
if x ...
x ? ... : ...
and the like you'll be fine.

You rarely need an actual true/false value in Ruby.

For more on this see
http://www.therailsway.com/2007/8/1/dangers-of-car...


--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denh...

Sean O'Halpin

11/15/2007 11:59:00 PM

0

On Nov 15, 2007 5:48 PM, Suraj Kurapati <snk@gna.org> wrote:
> Marc Heiler wrote:
> > (By the way, an accessor_read that can query variables with ? on the end
> > would be nice in std ruby too... I am not complaining at all, ruby is so
> > flexible, I already use this for my code and i love it, like @file.readable?
> > that queries a "special" reader accessor... i think it reads nicer than
> > @file.readable but this is just my opinion)
>
> Do you mean that attr_accessor treats symbols with a question mark
> differently by creating a "symbol_without_question=" writer method and a
> "symbol_with_question" reader method? For example:
>
> class Foo
> attr_acessor :readable? # defines Foo#readable= and Foo#readable?
> end
>
> f = Foo.new
> f.readable? #=> nil
> f.readable = 99
> f.readable? #=> 99
>
> This would be very useful, because it would make the following
> workaround obsolete:
>
> class Foo
> attr_writer :readable # only defines Foo#readable=
>
> def readable?
> @readable
> end
> end
>
> Oh wishing star, here is another wish for you! :-)
> 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

Todd Benson

11/16/2007 12:21:00 AM

0

On Nov 15, 2007 5:28 PM, Rick DeNatale <rick.denatale@gmail.com> wrote:
> On Nov 15, 2007 5:30 PM, James Britt <james.britt@gmail.com> wrote:
> >
> > Suraj Kurapati wrote:
>
> > > So, forcing question-mark methods to return only 'true' and 'false'
> > > feels far too restrictive and seems to follow a
> > > there's-only-one-way-to-do-it philosophy IMHO.
> >
> > Forcing would be bad, but there is the convention that foo? returns true
> > vs. false, not something vs. nil.
>
> There is no such convention in Ruby.

No convention in Ruby, but in Ruby programmers.

> > If a foo? method happens to be returning something other than TrueClass,
> > and you start depending on that quirk, you run the risk that a later
> > version of that method returns some other non-nil/non-false object.
>
> There ARE cases in the ruby language where a x? returns something
> other than true or false

Yes, that's great! No forcing, but just realizing that for your code
to work with others' requires some establishment of convention. Ruby
is a weird and happy monster that way. You can do almost anything
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.

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

a=nil
(a==a).class
#=> TrueClass

>
> The real danger is that you start testing 'truth' with expressions
> like x == true or x == false. As long as you don't do that and simply
> use the value in conditional expressions like
> if x ...
> x ? ... : ...
> and the like you'll be fine.
>
> You rarely need an actual true/false value in Ruby.

To newbies, this statement doesn't make much sense, but I do
understand where you're coming from. Newbies should definitely learn
that in a conditional, thinks are not always what they seem (and I
love it!).

a = 1
b = 2
a if b

> For more on this see
> http://www.therailsway.com/2007/8/1/dangers-of-car...

I didn't know this acquired the euphemism "cargo-culting". I still
thought it was called "script kiddies". I must be getting old :-)

> --
> Rick DeNatale
>
> My blog on Ruby
> http://talklikeaduck.denh...
>
>

Todd

James Britt

11/16/2007 2:23:00 AM

0

Todd Benson wrote:
> On Nov 15, 2007 5:28 PM, Rick DeNatale <rick.denatale@gmail.com> wrote:
>> On Nov 15, 2007 5:30 PM, James Britt <james.britt@gmail.com> wrote:
>>> Suraj Kurapati wrote:
>>>> So, forcing question-mark methods to return only 'true' and 'false'
>>>> feels far too restrictive and seems to follow a
>>>> there's-only-one-way-to-do-it philosophy IMHO.
>>> Forcing would be bad, but there is the convention that foo? returns true
>>> vs. false, not something vs. nil.
>> There is no such convention in Ruby.
>
> No convention in Ruby, but in Ruby programmers.

Right. And in a TIMTOWTDI language is can amount to the same thing.

>
>>> If a foo? method happens to be returning something other than TrueClass,
>>> and you start depending on that quirk, you run the risk that a later
>>> version of that method returns some other non-nil/non-false object.
>> There ARE cases in the ruby language where a x? returns something
>> other than true or false
>
> Yes, that's great! No forcing, but just realizing that for your code
> to work with others' requires some establishment of convention. Ruby
> is a weird and happy monster that way. You can do almost anything
> 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 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)