Ruby-dev summary 20201 - 20315

Hi all,

This is a summary of ruby-dev mailing list.

[ruby-dev:20268] splat restary

In 1.8.0, both asterisk prefixed parameter in method arguments
and parallel assignment operator ‘*’ would use to_ary and to_a
for conversion values to an array. Nobu Nakada fixed the
implementation of the feature.

[ruby-dev:20287] Is it bug of IRB?

As you know IRB is a nice interactive command tool to try
Ruby language and its features. NISHI Takao tried to
redefine Array#[] in IRB but it stopped because the IRB
is implemented in Ruby itself and use the Array class in it.
Keiju and Matz followed that, in order to use Ruby’s full features
in IRB, the implementation of IRB should be done in Array’s
subclasses, and that of Ruby be clean to execute IRB properly.

Why not do

myArray = Array.clone.freeze.new

and then implement irb w/ myArray.
That way changes in Array don’t affect the interpreter.

···

On Wed, Jun 04, 2003 at 12:36:13AM +0900, Kazuo Saito wrote:

Hi all,

This is a summary of ruby-dev mailing list.

[ruby-dev:20268] splat restary

In 1.8.0, both asterisk prefixed parameter in method arguments
and parallel assignment operator ‘*’ would use to_ary and to_a
for conversion values to an array. Nobu Nakada fixed the
implementation of the feature.

[ruby-dev:20287] Is it bug of IRB?

As you know IRB is a nice interactive command tool to try
Ruby language and its features. NISHI Takao tried to
redefine Array# in IRB but it stopped because the IRB
is implemented in Ruby itself and use the Array class in it.
Keiju and Matz followed that, in order to use Ruby’s full features
in IRB, the implementation of IRB should be done in Array’s
subclasses, and that of Ruby be clean to execute IRB properly.


_ _

__ __ | | ___ _ __ ___ __ _ _ __
'_ \ / | __/ __| '_ _ \ / ` | ’ \
) | (| | |
__ \ | | | | | (| | | | |
.__/ _,
|_|/| || ||_,|| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

  • SynrG notes that the number of configuration questions to answer in sendmail
    is NON-TRIVIAL
    – Seen on #Debian

[ruby-dev:20268] splat restary

In 1.8.0, both asterisk prefixed parameter in method arguments
and parallel assignment operator ‘*’ would use to_ary and to_a
for conversion values to an array. Nobu Nakada fixed the
implementation of the feature.

What exactly does this mean? Do both forms of ‘*’ now use the same
method for conversion to array? If so, which one?

[ruby-dev:20287] Is it bug of IRB?

As you know IRB is a nice interactive command tool to try
Ruby language and its features. NISHI Takao tried to
redefine Array# in IRB but it stopped because the IRB
is implemented in Ruby itself and use the Array class in it.
Keiju and Matz followed that, in order to use Ruby’s full features
in IRB, the implementation of IRB should be done in Array’s
subclasses, and that of Ruby be clean to execute IRB properly.

So redefining Array# in irb would actually modify a subclass of Array
and not Array itself? Or would irb use a subclass of Array?

Paul

···

On Wed, Jun 04, 2003 at 12:36:13AM +0900, Kazuo Saito wrote:

What exactly does this mean? Do both forms of '*' now use the same
method for conversion to array? If so, which one?

svg% cat b.rb
#!/usr/bin/ruby
class A
   def to_a
      [1, 2]
   end
end

def a(*args)
   p args
end

a(*A.new)
svg%

svg% ruby b.rb
[1, 2]
svg%

Guy Decoux

IMO, this is indicative of a more general problem than just IRB. If
one module changes Array, code in another module might not be compatible
with those changes. Ideally it should be possible to isolate changes to
builtin classes to a single module. I’d wager that’s even harder to
implement than it sounds, though.

Paul

···

On Wed, Jun 04, 2003 at 06:50:39PM +0900, Mauricio Fernández wrote:

Why not do

myArray = Array.clone.freeze.new

and then implement irb w/ myArray.
That way changes in Array don’t affect the interpreter.

This topic came up at RubyConf 2001 during David Black’s Ruby Behaviors
talk. David Simmons (creator of SmallScript or S#) suggested the need for
something called “selector namespaces”, which has been discussed (with
David’s input) in ruby-talk:18567.

Still interesting and still a challenge. :slight_smile:

Chad

···

On Thu, 5 Jun 2003, Paul Brannan wrote:

On Wed, Jun 04, 2003 at 06:50:39PM +0900, Mauricio Fernández wrote:

Why not do

myArray = Array.clone.freeze.new

and then implement irb w/ myArray.
That way changes in Array don’t affect the interpreter.

IMO, this is indicative of a more general problem than just IRB. If
one module changes Array, code in another module might not be compatible
with those changes. Ideally it should be possible to isolate changes to
builtin classes to a single module. I’d wager that’s even harder to
implement than it sounds, though.

i do this alot:

module FooBar
class Array < ::Array
end
end

which is a partial fix.

-a

···

On Thu, 5 Jun 2003, Paul Brannan wrote:

IMO, this is indicative of a more general problem than just IRB. If
one module changes Array, code in another module might not be compatible
with those changes. Ideally it should be possible to isolate changes to
builtin classes to a single module. I’d wager that’s even harder to
implement than it sounds, though.

Ara Howard
NOAA Forecast Systems Laboratory
Information and Technology Services
Data Systems Group
R/FST 325 Broadway
Boulder, CO 80305-3328
Email: ara.t.howard@noaa.gov
Phone: 303-497-7238
Fax: 303-497-7259
~ > ruby -e ‘p % ^) .intern’
====================================

It’s actually not all that difficult under some circumstances, but
there are some costs associated with it. Basically what you need is
both lexical namespaces and namespace overlays. Not a trivial task,
by any means, but doable if you need it. (Whether it’s worthwhile or
not is a separate issue, of course)

···

At 2:34 AM +0900 6/5/03, Chad Fowler wrote:

On Thu, 5 Jun 2003, Paul Brannan wrote:

On Wed, Jun 04, 2003 at 06:50:39PM +0900, Mauricio Fernández wrote:

Why not do

myArray = Array.clone.freeze.new

and then implement irb w/ myArray.
That way changes in Array don’t affect the interpreter.

IMO, this is indicative of a more general problem than just IRB. If
one module changes Array, code in another module might not be compatible
with those changes. Ideally it should be possible to isolate changes to
builtin classes to a single module. I’d wager that’s even harder to
implement than it sounds, though.

This topic came up at RubyConf 2001 during David Black’s Ruby Behaviors
talk. David Simmons (creator of SmallScript or S#) suggested the need for
something called “selector namespaces”, which has been discussed (with
David’s input) in ruby-talk:18567.


Dan

--------------------------------------“it’s like this”-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk

This topic came up at RubyConf 2001 during David Black’s Ruby Behaviors
talk. David Simmons (creator of SmallScript or S#) suggested the
need for
something called “selector namespaces”, which has been discussed (with
David’s input) in ruby-talk:18567.

It’s actually not all that difficult under some circumstances, but
there are some costs associated with it. Basically what you need is
both lexical namespaces and namespace overlays. Not a trivial task, by
any means, but doable if you need it. (Whether it’s worthwhile or not
is a separate issue, of course)

Could you whip us up a quick working prototype so we can see how it
feels? :wink:

But, seriously, will parrot have these features?

Chad

This topic came up at RubyConf 2001 during David Black’s Ruby Behaviors
talk. David Simmons (creator of SmallScript or S#) suggested the need for
something called “selector namespaces”, which has been discussed (with
David’s input) in ruby-talk:18567.

It’s actually not all that difficult under some circumstances, but
there are some costs associated with it. Basically what you need is
both lexical namespaces and namespace overlays. Not a trivial task,
by any means, but doable if you need it. (Whether it’s worthwhile
or not is a separate issue, of course)

Could you whip us up a quick working prototype so we can see how it feels? :wink:

I’ve already got perl and parrot’s internals wedged into my brain–if
I added Ruby’s, well, I expect Horrible Lovecraftian Things would
happen. Not, mind, that anyone’s likely to notice, but still… :slight_smile:

But, seriously, will parrot have these features?

Yeah, it’s an outgrowth of the support needed for some of Python’s
namespace stuff, so it’ll be in there. I’m not thrilled about the
cost, but there’s pie involved, so one does what one must.

Selector Namespaces, for those who’re following along, are
essentially lexical namespaces. They allow you to have a local
override to a global (generally) name, or a name that only exists
inside a lexical scope. This way you can have, for example, a Foo
method for class Bar that only is visible in some scope–it may mask
an existing Foo, or may be brand new and only exist inside that
scope. This way you can have private versions of methods, private
methods, and even private classes if you want.

To make this work, generally you need nested name tables. Each
lexical scope has a pointer to a name table, and when you go look up
a name, you look in the lexical table. Each lexical table has a
pointer to an outer table, which potentially points to its outer
table, and so forth. When you look a name up, you walk up the tables
until you find the name, or fail.

As you can imagine, this makes name lookup a bit slower, since you
probably have to walk several levels, and makes scope changing a bit
more complex, since you need to save and restore these pointers.
Doable, certainly, and it provides a lot of power, but the places its
useful are somewhat restricted.

···

At 11:00 AM +0900 6/5/03, Chad Fowler wrote:

                                     Dan

--------------------------------------“it’s like this”-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk