Gavin Sinclair wrote:
I find #one quite uncompelling,
because it sounds like #any: it doesn't express its one_and_only_one
meaning.
Instead of "one", why not "lone", e.g. The Lone Ranger?
--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/>
Hi --
On Mon, 29 Nov 2004, Gavin Sinclair wrote:
On Monday, November 29, 2004, 3:53:43 PM, David wrote:
>> > I'm not sure what either of these adds to const_get -- or, to put it
>> > another way, why there should be a special method to do (essentially)
>> > a const_get only for strings that represent class names.
>>
>> Well, IIRC, const_get doesn't work with symbols that contain "::". In
>> other words, const_get( "Test::Unit" ) would fail--you'd have to do
>> const_get("Test").const_get("Unit"), which becomes cumbersome. I can
>> think of several instances in my Net::SSH and Net::SFTP stuff alone
>> where a standard #get_class method would have been useful (though far
>> from necessary).> Oh right, I forgot about that. There are some "deep" const_get
> implementations floating around... along the lines of:> def deep_const_get(str)
> str.split('::').inject(Object) {|a,b| a.const_get(b) }
> end> which might help.
That's precisely how it's implemented in extensions. BTW it's now
Class.by_name.Class.by_name("::Test::Unit") -> Test::Unit
Is this restricted to Class objects?
David
--
David A. Black
dblack@wobblini.net
Glenn Parker wrote:
Gavin Sinclair wrote:
I find #one quite uncompelling,
because it sounds like #any: it doesn't express its one_and_only_one
meaning.Instead of "one", why not "lone", e.g. The Lone Ranger?
Let's call it #singleton 
Why not #scalar as it returns the scalar value of the array if the array is a 1-tuple.
Regards,
Brian
On Tue, 30 Nov 2004 11:32:13 +0900 Glenn Parker <glenn.parker@comcast.net> wrote:
Gavin Sinclair wrote:
> I find #one quite uncompelling,
> because it sounds like #any: it doesn't express its one_and_only_one
> meaning.Instead of "one", why not "lone", e.g. The Lone Ranger?
--
Brian Schröder
http://www.brian-schroeder.de/
No. It's defined in Module as
class Module
def Module.by_name(name)
name = name.to_str.sub(/^::([A-z])/, '\1')
name.split(/::/).inject(Object) { |mod, name| mod.const_get(name) }
end
end
So trailing constants in a path are accepted, like
Shapes::Circle::MAX_RADIUS
Hadn't thought of that...
Gavin
On Monday, November 29, 2004, 10:15:36 PM, David wrote:
> Oh right, I forgot about that. There are some "deep" const_get
> implementations floating around... along the lines of:> def deep_const_get(str)
> str.split('::').inject(Object) {|a,b| a.const_get(b) }
> end> which might help.
That's precisely how it's implemented in extensions. BTW it's now
Class.by_name.Class.by_name("::Test::Unit") -> Test::Unit
Is this restricted to Class objects?
Glenn Parker wrote:
> Gavin Sinclair wrote:
>> I find #one quite uncompelling,
>> because it sounds like #any: it doesn't express its one_and_only_one
>> meaning.
>
> Instead of "one", why not "lone", e.g. The Lone Ranger?
Array#tonto
Let's call it #singleton
LOL 
On Monday 29 November 2004 10:29 pm, Joel VanderWerf wrote:
Sorry for the noise, I read the rejection further down only after sending this. (Though I still think #to_scalar more natural than #one, because #one does not convey a clear meaning to me)
e.g.
.one => 1 (It returns one?)
.one => true (It is only one array?)
[:a,:b,:c,:d].one => [1,1,1,1] (Fill with ones?)
Regards,
Brian
On Tue, 30 Nov 2004 19:14:59 +0900 Brian Schröder <ruby@brian-schroeder.de> wrote:
On Tue, 30 Nov 2004 11:32:13 +0900 > Glenn Parker <glenn.parker@comcast.net> wrote:
> Gavin Sinclair wrote:
> > I find #one quite uncompelling,
> > because it sounds like #any: it doesn't express its one_and_only_one
> > meaning.
>
> Instead of "one", why not "lone", e.g. The Lone Ranger?
>
Why not #scalar as it returns the scalar value of the array if the array is a 1-tuple.
--
Brian Schröder
http://www.brian-schroeder.de/
At first it occurred to me that this is nothing more than Array#first, except
that an error is desired if it isn't single. But this led me to another
oddity about #first, you can;t distinguish the results of these two forms:
.first
[nil].first
To improve upon this leads me to three possibilities:
1) Live with it. It's manegable.
2) Introduce the concept of nack --which is an encapsulated
and diverted error. This has certain advantages, but
it is a "bigger" change.
.first #=> nack
(f = .first).nack_raise #=> (Exception)
where #nack_raise is defined in kernel to raise the nack if
it is one other wise return self.
3) Add a parameter to #first.
.first(:empty) #=> (Exception)
[1].first(:empty) #=> 1
[1,2].first(:empty) #=> 1
.first(:only) #=> (Exception)
[1].first(:only) #=> 1
[1,2].first(:only) #=> (Exception)
T.
On Tuesday 30 November 2004 05:25 am, Brian Schröder wrote:
Sorry for the noise, I read the rejection further down only after sending
this. (Though I still think #to_scalar more natural than #one, because #one
does not convey a clear meaning to me)e.g.
.one => 1 (It returns one?)
.one => true (It is only one array?)
[:a,:b,:c,:d].one => [1,1,1,1] (Fill with ones?)