A new version of Ruby/Extensions, a suite of useful methods added to
Ruby’s built-in classes, has been released. Version 0.3 consolidates 8
new or improved methods since version 0.2.
A new version of Ruby/Extensions, a suite of useful methods added to
Ruby’s built-in classes, has been released. Version 0.3 consolidates 8
new or improved methods since version 0.2.
Gavin,
I like this project and I hope to add to it from time to time.
The other day I was having trouble thinking of the name of the project,
however. I think this is because I associate the term “extension” in
Rubyland with C extensions, whereas this is a pure-Ruby project (is it
not?).
Do you think the confusion would be great enough to justify changing
the name? Just a thought. Your project, not mine.
first let me say that i think this is a very admirable project. it provides
some stadardization to standard class methods that are not quite common
enough to be included in ruby proper, as well as “trial arena” for possible
inclusion into ruby proper in the future.
i am wondering, given the stated goals, in what direction you plan to proceed
as submissions are made to the project? will you further modularize the
extensions or will you instead limit what can be a part of these extensions?
for instance, in my programs i sometimes include my own modifications to ruby
core classes, one of the main changes consits of some method additions to
NilClass.
class NilClass
def to_f; 0.0; end
def to_h; {}; end
def empty?; true; end
alias size to_i
alias length to_i
end
how might this fit in with the project?
thanks,
T.
···
On Friday 23 January 2004 02:06 pm, Gavin Sinclair wrote:
A new version of Ruby/Extensions, a suite of useful methods added to
Ruby’s built-in classes, has been released. Version 0.3 consolidates 8
new or improved methods since version 0.2.
A new version of Ruby/Extensions, a suite of useful methods added to
Ruby’s built-in classes, has been released. Version 0.3 consolidates 8
new or improved methods since version 0.2.
May I make the suggestion of adding in some convenience methods for the
Time class for manipulating dates, similar to what Javascript has?
http://phrogz.net/ObjJob/object.asp?id=224
shows the full list of methods, and in particular I’m thinking of
methods that allow you to set the date (day number) without having to
muck about with seconds.
For example, the following JS code is quite common for figuring a day at
some point in the future:
var nextWeek = new Date();
nextWeek.setDate(nextWeek.getDate()+7);
//JS internally modifies the number of milliseconds,
//so if the day number is ‘invalid’, it actually wraps
//to the next month.
In Ruby this could be like:
nextWeek = Time.new
nextWeek.date+=7;
If you’d like me (novice developer) to take a stab at an initial
implementation of these, I’d be happy to.
Those methods make sense only in very specific cases. They assume you
want +nil+ to be like a valid string, integer, array, etc. That’s an
assumption I (almost) never want to make in my code.
One of the stated goals of the project is that methods be general
purpose. That’s a pretty vague aim, but it’s pretty clear that the
methods above are not general purpose.
Cheers,
Gavin
···
On Saturday, January 24, 2004, 5:07:40 AM, T. wrote:
[…]
i am wondering, given the stated goals, in what direction you plan to proceed
as submissions are made to the project? will you further modularize the
extensions or will you instead limit what can be a part of these extensions?
for instance, in my programs i sometimes include my own modifications to ruby
core classes, one of the main changes consits of some method additions to
NilClass.
class NilClass
def to_f; 0.0; end
def to_h; {}; end
def empty?; true; end
alias size to_i
alias length to_i
end
Such confusion has certainly occurred to me. The project is
sort-of-called “Ruby/Extensions” but of course the RubyForge “unix”
name is “extensions”, which is a bit too general perhaps.
But I’ve never thought of anything better. Feel free to suggest.
Cheers,
Gavin
···
On Saturday, January 24, 2004, 3:58:49 AM, Hal wrote:
Gavin Sinclair wrote:
A new version of Ruby/Extensions, a suite of useful methods added to
Ruby’s built-in classes, has been released. Version 0.3 consolidates 8
new or improved methods since version 0.2.
Gavin,
I like this project and I hope to add to it from time to time.
The other day I was having trouble thinking of the name of the project,
however. I think this is because I associate the term “extension” in
Rubyland with C extensions, whereas this is a pure-Ruby project (is it
not?).
Do you think the confusion would be great enough to justify changing
the name? Just a thought. Your project, not mine.
May I make the suggestion of adding in some convenience methods for the
Time class for manipulating dates, similar to what Javascript has?
OK, so for some reason I totally missed the Date class in the standard
library. I think I’ll take a long look at it before attempting to renew
this suggestion
May I make the suggestion of adding in some convenience methods for the
Time class for manipulating dates, similar to what Javascript has?
I think Time#year, #month, #week and #day could be useful. (#hour and #minute seem to be a bit extreme, but they might still be added.)
What about adding these: (taken from good_time.rb ;))
This makes Time act more like the Enumerable it really is
It also adds some Time travel methods
class Time
class Slice < Array; end
extend Enumerable
def succ
self + 1
end
def upto(other)
self.to_i.upto(other.to_i) { |item| yield Time[item] }
end
def downto(other)
self.to_i.downto(other.to_i) { |item| yield Time[item] }
end
class << self
def
args = args.first … (args.first + args.last) if args.length == 2
index = args.first
unless index.is_a? Range
at(index)
else
index.inject(Time::Slice.new) {|state, item| state << at(item)}
end
end
def first; self[0]; end
def last; self[2**31-1]; end
def each
first.upto(last) { |item| yield item }
end
alias :old_now :now
def now;
at(old_now.to_i + (@offset || 0))
end
attr_accessor :offset
def set(to)
@offset ||= 0
@offset += to.to_i - Time.now.to_i
now
end
alias :goto :set
alias :travel :set
def rewind; goto(Time.first); end
# optimizations
def max; last; end
def min; first; end
def include?(item); (first..last).include? item; end
alias :member? :include?
Those methods make sense only in very specific cases. They assume you
want +nil+ to be like a valid string, integer, array, etc. That’s an
assumption I (almost) never want to make in my code.
do you think NilClass’ to_a and to_i methods should be removed then?
One of the stated goals of the project is that methods be general
purpose. That’s a pretty vague aim, but it’s pretty clear that the
methods above are not general purpose.
hmm… to me they seem even more general purpose then most, since they are so
very basic. the differnce is whether one views the NilClass as a
representation of “emptiness” vs. “notness” (for lack of better words). my
additional methods thus adding in the way on the point of view of
“emptiness”. in my experience (and honestly a bit to my suprise) i have never
run into any difficulties by including these methods and putting to use these
two different conceptions of nil; though sometimes i do think it might be
nice to separate the “notness” out into a separate NackClass, all the same.
anyway, i think you’ve answered my question. Ruby/Extensions is intended as a
restricted set of approved inclusions rather than an open collection of
acceptable inclusions. that’s fine. i just wanted to be clear on the goals of
the project.
thanks gavin,
T.
···
On Saturday 24 January 2004 12:58 am, Gavin Sinclair wrote:
The difference between art and science is that science is what we
understand well enough to explain to a computer.
Art is everything else.
– Donald Knuth, “Discover”
/bin/sh -c ‘for l in ruby perl;do $l -e “print "\x3a\x2d\x29\x0a"”;done’
===============================================================================
Those methods make sense only in very specific cases. They assume you
want +nil+ to be like a valid string, integer, array, etc. That’s an
assumption I (almost) never want to make in my code.
…
anyway, i think you’ve answered my question. Ruby/Extensions is intended
as a restricted set of approved inclusions rather than an open collection
of acceptable inclusions. that’s fine. i just wanted to be clear on the
goals of the project.
I don’t think that’s what Gavin said at all. I don’t particularly consider
your additions to NilClass to be “acceptable.” I certainly treat nil as a
non-value, not an empty value. If I think that I might get a nil value, I always test for #nil?. It might be okay to have NilClass#to_s (or is it #to_str) return ‘’ (nil-string), but I personally don’t ever rely on the
NilClass#to_a or NilClass#to_i behaviours.
-austin
···
On Sat, 24 Jan 2004 11:13:35 +0900, T. Onoma wrote:
On Saturday 24 January 2004 12:58 am, Gavin Sinclair wrote:
–
austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2004.01.23
* 22.41.00
i’m with you austin - that way leads to p*** style debugging sessions!
-a
···
On Sat, 24 Jan 2004, Austin Ziegler wrote:
Date: Sat, 24 Jan 2004 12:44:54 +0900
From: Austin Ziegler austin@halostatue.ca
Newsgroups: comp.lang.ruby
Subject: Re: [ANN] Ruby/Extensions v0.3 released
On Sat, 24 Jan 2004 11:13:35 +0900, T. Onoma wrote:
On Saturday 24 January 2004 12:58 am, Gavin Sinclair wrote:
Those methods make sense only in very specific cases. They assume you
want +nil+ to be like a valid string, integer, array, etc. That’s an
assumption I (almost) never want to make in my code.
…
anyway, i think you’ve answered my question. Ruby/Extensions is intended
as a restricted set of approved inclusions rather than an open collection
of acceptable inclusions. that’s fine. i just wanted to be clear on the
goals of the project.
I don’t think that’s what Gavin said at all. I don’t particularly consider
your additions to NilClass to be “acceptable.” I certainly treat nil as a
non-value, not an empty value. If I think that I might get a nil value, I always test for #nil?. It might be okay to have NilClass#to_s (or is it #to_str) return ‘’ (nil-string), but I personally don’t ever rely on the
NilClass#to_a or NilClass#to_i behaviours.
The difference between art and science is that science is what we
understand well enough to explain to a computer.
Art is everything else.
– Donald Knuth, “Discover”
/bin/sh -c ‘for l in ruby perl;do $l -e “print "\x3a\x2d\x29\x0a"”;done’
===============================================================================
how does one define acceptable? is it not enough that suggestions for such
methods reoccur often on ruby-talk? or just that you “personally don’t ever
rely on” them? or for gavin, “that’s an assumption I (almost) never want to
make in my code.” hence the indication of “approved” rather then
“acceptable”. moreover, i think your argument would be much more
understandable if there were no precedence for such methods, but since to_a
and to_i are already present, then to some extent such methods are already
acceptable. but i may be assuming to much, and stand corrected if i’ve
overread.
as to the use itself. these method provide a means to circumvent having to
implement type and error checks when it is not important, that is, when
“emptiness” is meant, much like default parameters allow us to circumvent having to supply method prameters. obviously it is not neccessary, but
being able to drop a #to_f or #empty? call on a method or variable that may
return nil when a float or array is typically expected can be very
convenient, saving us extraneous ‘if x != nil’ clauses.
one may argue that using such methods goes against good coding practices. yet
one of the things i like about ruby is that it lets me decide which
–convenience vs. when proper coding practice, is of most importance for a
given problem.
anyway, it dosen’t much matter a great deal to me. I was just trying to get a
feel for what “scope” of inclusion Ruby/Extentions was going to provide.
thanks,
T.
···
On Saturday 24 January 2004 04:44 am, Austin Ziegler wrote:
I don’t think that’s what Gavin said at all. I don’t particularly consider
your additions to NilClass to be “acceptable.” I certainly treat nil as a
non-value, not an empty value. If I think that I might get a nil value, I always test for #nil?. It might be okay to have NilClass#to_s (or is it #to_str) return ‘’ (nil-string), but I personally don’t ever rely on the
NilClass#to_a or NilClass#to_i behaviours.
I don’t think that’s what Gavin said at all. I don’t particularly consider
your additions to NilClass to be “acceptable.” I certainly treat nil as a
non-value, not an empty value. If I think that I might get a nil value, I always test for #nil?. It might be okay to have NilClass#to_s (or is it #to_str) return ‘’ (nil-string),
Personally I’d prefer to not even have Nilclass#to_s since it converts a
false value into a true value which to me seems to be unintuitive.
Also I’d prefer
put nil
to print nil rather than an empty string
Nilclass#to_str would be even worse since that would allow code like
x = nil
puts x + “a string” #=> “a string”
if x wasn’t supposed to be nil then that could lead to a lot of long
debugging sessions
Yes, nice one. That doesn’t capture the essense of the project,
though, which is strictly extensions to built-in classes. “Toolbox”
sounds more general.
Perhaps ‘sce’. Not pretty, but definitive. But D’OH! RubyForge
insists on 4-letter names
Gavin
···
On Saturday, January 24, 2004, 9:10:06 PM, Simon wrote:
On Fri, 23 Jan 2004 21:57:13 -0700, Ara.T.Howard wrote:
On Sat, 24 Jan 2004, Gavin Sinclair wrote:
Date: Sat, 24 Jan 2004 09:02:10 +0900
From: Gavin Sinclair gsinclair@soyabean.com.au
Newsgroups: comp.lang.ruby
Subject: Re: [ANN] Ruby/Extensions v0.3 released
> But I've never thought of anything better. Feel free to suggest.
boost
toolbox
enhance
extras
standard class extensions → sce
