From: GGarramuno@... (GGarramuno)
Date: 2004-01-14T06:36:37+09:00
Subject: Re: faster integer arithmetics & arbitrary precision floating number

Gavin Sinclair <gsinclair@soyabean.com.au> wrote in message news:<16176736811.20040113210844@soyabean.com.au>...
> On Tuesday, January 13, 2004, 2:21:37 PM, GGarramuno wrote:
> 
> Like many things about Ruby: a problem in theory (or can be construed
> as such), but not in practice.
> 

Disagree.  I'm new to the language and I am evaluating it to see if it
is worth investing on it and I can tell you this is NOT a minor issue.
 For me, it is the first real big, big, big problem to consider ruby
as a scripting replacement to current tools.

Just look at irb.  Try doing:

irb> methods(String) 

or similar in it and see the dozen or so methods that should remain
internal to irb exposed to the user.  A pretty ugly mess already when
debugging code.
And consider that ruby's user base and library is still small, I think
there's still hope to address this before it really becomes a true
issue.

> Such namespaces will possibly/probably bew a core language feature in
> the near future.  See Matz's slides on the future of Ruby from the last
> conference.
> 

Thanks, saw the slides.  The namespace feature as presented is a bad
one as it would lead to a mess when you have the need for namespaces
to become nested or work across multiple files.
For that to work, imo, you need at least three directives: one to open
a new namespace, one to close it, and one to throw away the namespace.
 For true power, you could indeed extend that to 4 directives, as
David's Behavior module does but it would be harder and likely a
memory pig as you would be force to store all namespaces of all code
for the duration of the program.

But, with 3 directives you would avoid the issue of ugly code such as:

namespace added_to_kernel
   namespace added_to_string
        my real code
   end
end

and instead could have much nicer code as:

namespace add_stuff_to_kernel
end
namespace add_stuff_to_string
end

my real code

drop namespace add_stuff_to_string
drop namespace add_stuff_to_kernel

# or even reverse the use of drop directives 
# (to, say, remove kernel, but leave string... something in which the
#  nested syntax also presents problems)
# this would allow to build stand-alone modules much more easily.
# But this power should also come with a safety net to have a 
# way to list namespaces and their contents for debugging, too.
# And as matz pointed out in the slide, I am really afraid of
efficiency,
# considering ruby is not exactly a speed daemon already.


But... again, the more I think about it, the more I like python's
approach to this as it is simpler, faster and leading to less
problems.  Mind you, I HATE python with a passion (for other reasons,
thou).
The benefit of, say, having something like system() do exceptions and
printing is NOT compelling enough to me.  The only area where that
feature would be a true godsend is if I were doing a debugger, as I
could track resources with only a couple of lines of code (which I
assume is why irb does what it does).

Also, the word "namespace" is likely also not a good idea as namespace
refers to modules in popular languages (C++, etc).