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.
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
On Feb 13, 2008 2:32 PM, Joel VanderWerf [email protected]
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
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.
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.
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?
My latest wish–a GC that actually worked, instead of mongrel processes
that take 600MB and growing
lol
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
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.
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?
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
On Mon, Oct 15, 2007 at 7:23 AM, Roger P. [email protected]
wrote:
- 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 
- 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
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.
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).
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
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
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…
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
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 
)
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
I actually like this setup since it helps describe the parameters.
Thanks
-R
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
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