Ruby wish-list


#81

On Feb 13, 2008, at 2:56 PM, Roger P. wrote:

or maybe not even use brackets at all–they confuse with their
similarity to arrays.
Thoughts?

I tend to define [] and []= whenever possible if the object behaves
like an indexed collection of objects. I think this helps with duck-
typing. If every collection had a different manner of indexing items
it would defeat any duck-typing.

Less common, but also useful is to provide fetch/store in addition to
[] and []=. The fetch API is nice when you want to substitute a
different default value:

fetch(index) # get item or raise exception
fetch(index, miss) # get item or return miss
fetch(index) { } # get item or compute miss

Gary W.


#82

I tend to define [] and []= whenever possible if the object behaves
like an indexed collection of objects. I think this helps with duck-
typing. If every collection had a different manner of indexing items
it would defeat any duck-typing.

Interesting. Is there a common delete api?
Cheers.
=roger


#83

On Feb 13, 2008 2:32 PM, Joel VanderWerf removed_email_address@domain.invalid
wrote:

so (whatever Hash#- does) it involves making a copy of the hash and
changing that instead, whereas #delete is destructive.

Which means if you use #- you’re creating a new object and #delete
does not, right? It may not be much of a drain, but you want to cut
back on object creation when it’s obviously superfluous, right?

Ben


#84

Roger P. wrote:

hash -= ‘a’ # instead of delete

That would be the same as

hash = hash - ‘a’

so (whatever Hash#- does) it involves making a copy of the hash and
changing that instead, whereas #delete is destructive.


#85

Yeah my wish would be for a syntax that “makes sense” for deleting
objects (seeing that [] adds them) which wouldn’t create new objects but
would act like delete.
:slight_smile:
Just wishing.

Which means if you use #- you’re creating a new object and #delete
does not, right? It may not be much of a drain, but you want to cut
back on object creation when it’s obviously superfluous, right?


#86

My latest wish–a GC that actually worked, instead of mongrel processes
that take 600MB and growing :slight_smile:
lol


#87

On Feb 13, 2008, at 11:36 PM, Roger P. wrote:

My latest wish–a GC that actually worked, instead of mongrel
processes
that take 600MB and growing :slight_smile:

You can’t determine from the size of a process whether the GC is
working or not since memory (even when freed by the GC) is never
returned to the OS. So with a magic 100% perfect GC, the memory
footprint of your process will always reflect its peak memory usage.

You also have to determine if the GC is failing to collect dead
objects or if you simply have some obscure references that are
keeping large groups of objects on life support.

Gary W.


#88

I personally hate elsif [as opposed to elseif or else if]. I imagine it
comes from some lesser language. Come on, is ‘e’ so damn hard to type?


#89

You can’t determine from the size of a process whether the GC is
working or not since memory (even when freed by the GC) is never
returned to the OS. So with a magic 100% perfect GC, the memory
footprint of your process will always reflect its peak memory usage.

that being the case then my wish would be clarified as a GC that was
fast and freed memory when no longer needed (appropriately and
bug-free).
Cheers!
-Roger


#90

On Mon, Oct 15, 2007 at 7:23 AM, Roger P. removed_email_address@domain.invalid
wrote:

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

Is available in JRuby :slight_smile:

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

Not sure if anyone has mentioned that already, but this is simply a
matter of either changing TRACE_HEAD and TRACE_TAIL #defines, and
recompiling Ruby, or wrapping your “main” in something like

begin

rescue Object => e
puts e.message
print ’ ’
puts e.backtrace.join("\n ")
exit -1
end


#91

Hi,

At Fri, 15 Feb 2008 06:50:23 +0900,
Suraj K. wrote in [ruby-talk:291073]:

Alexey V. wrote:

puts e.backtrace.join("\n ")

puts e.backtrace

puts will automatically insert the platform-dependent line-break for
you.

Alexey uses indentation.

(Note that join("\n") is not sufficient to produce proper
line-breaks on Windows).

Not true always. It depends on whether the output is opened in
text mode or in binary mode.


#92

Alexey V. wrote:

puts e.backtrace.join("\n ")

puts e.backtrace

puts will automatically insert the platform-dependent line-break for
you. (Note that join("\n") is not sufficient to produce proper
line-breaks on Windows).


#93

Roger P. wrote:

My next wish, ruby-genie!
Some type of variable that holds the ‘last return value’
so, for example, in irb

35+89
=> 124

b = _____ # meaning it should be set equal to 124

irb(main):001:0> 35+89
=> 124
irb(main):002:0> _
=> 124


#94

Not sure if anyone has mentioned that already, but this is simply a
matter of either changing TRACE_HEAD and TRACE_TAIL #defines, and
recompiling Ruby, or wrapping your “main” in something like

Yeah I’ve done that before and it’s like a breath of fresh air when the
output includes the entire trace. Ahh.

My next wish, ruby-genie!
Some type of variable that holds the ‘last return value’
so, for example, in irb

35+89
=> 124

b = _____ # meaning it should be set equal to 124

:slight_smile:


#95

Joel VanderWerf wrote:

irb(main):001:0> 35+89
=> 124
irb(main):002:0> _
=> 124

awesome. Thanks.


#96

Alexey V. wrote:

print ’ ’
puts e.backtrace.join("\n ")
exit -1
end

Note that $! (which contains the current exception) is still defined
when Ruby is about to exit on an exception, while it’s processing the
END blocks. You can get the same effect without wrapping main by adding
your exception printing code in an END block, which can be anywhere:

END { puts $!.backtrace*"\n\t" }

Clifford H…


#97

Hi –

On Sat, 22 Mar 2008, Roger P. wrote:

end

end

def method_1 a, b, c
verify_params a => Number, b => String

end

Ahh. Type checking at last.

It’s class checking actually, not type checking. Type is different
from class in Ruby.

David


#98

Roger P. wrote:

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

I guess it’s been suggested here before, but I have often wished for a
way to have ‘tighter’ control over the variables passed to a parameter.
Sometimes duck typing doesn’t immediately catch errors, until you run
through certain (possibly rare sequences). So anyway my wish is for
checking of parameters. Fortunately it seems already possible (as about
30% of rush wishes seem :stuck_out_tongue: )

a class to match

class Number
def Number.matches? param
return true if param.class == Fixnum or param.class == Float or
param.class == BigDecimal
end
end

def verify_params params_to_verify
for param, should_match_this_class in params_to_verify do
if should_match_this_class.respond_to? :matches?
raise ‘poor parameter’ unless should_match_this_class.matches?
param
else
raise ‘poor parameter’ unless param.class ==
should_match_this_class
end
end

end

def method_1 a, b, c
verify_params a => Number, b => String

end

Ahh. Type checking at last.
Ok you may begin to throw the stones :slight_smile:
I actually like this setup since it helps describe the parameters.
Thanks :slight_smile:

-R


#99

It’s class checking actually, not type checking. Type is different
from class in Ruby.

David

In that case I shall refer to it as “parameter verification” nobody
would disagree with that :slight_smile:


#100

Hi,

At Sat, 22 Mar 2008 07:33:56 +0900,
Roger P. wrote in [ruby-talk:295325]:

a class to match

class Number
def Number.matches? param
return true if param.class == Fixnum or param.class == Float or
param.class == BigDecimal
end
end

Numeric === obj