Hi –
An open question for Matz:
Is anything disappearing from Ruby in 2.0? Not that I have a very big
list of things I want removed 
but I’m wondering, for example,
about the Perl-like special variables. And just wondering generally
if there’s anything in that category.
David
–
David A. Black
dblack@wobblini.net
David A. Black wrote:
Hi –
An open question for Matz:
Is anything disappearing from Ruby in 2.0? Not that I have a very big
list of things I want removedbut I’m wondering, for example,
about the Perl-like special variables. And just wondering generally
if there’s anything in that category.
If the perlish globals are going away, then that suggests another
possibility that would make the remaining globals more regular. I often
have to look up which globals are per-thread (and this was especially
true when I was starting out with ruby). What if the name of the global
determined in a very simple way whether is was per-thread or not?
For example, the rule could be: all globals matching /$\w*/ are
per-thread. All others are per-process. That’s consistent with the
current use of $, which is per-thread.
What breaks? Well, if you take out all the perlish variables from the
list in the Pickaxe (pp.216-218), the only variable whose behavior would
change is $SAFE. So that would have to be replaced with $SAFE, or left
as a special case (perhaps with a warning, and expiring after a while).
I’d rather remember one special case than two pages of them. The
standard library is unaffected, aside from any use of $SAFE, since there
are no variables in it that match /$\w+/. Same goes for all the RAA
projects that I’ve downloaded.
This change would also make it easy to work with user-defined thread
local variables. Instead of
Thread.new {
Thread.current[:foo] = 3
}
you could simply do
Thread.new {
$_foo = 3
}
I guess that’s probably more efficient, too, since it saves a method call.
Hi,
Is anything disappearing from Ruby in 2.0? Not that I have a very big
list of things I want removed
about the Perl-like special variables. And just wondering generally
if there’s anything in that category.
Candidates are:
Perl style variables
…/… in condition
regex literal in condition
Prec module
maybe a few other things I can’t think of now
matz.
In message “anything disappearing from Ruby for 2.0?” on 03/11/29, “David A. Black” dblack@wobblini.net writes:
What does “condition” refer to here? Just the expression of an
if/while/unless, or also the ‘when’ expression in a case? I don’t see
any reason to lose when /regex/, since it quite orthogonally calls
=== with the case argument . . .
-Mark
On Sun, Nov 30, 2003 at 02:01:39AM +0900, Yukihiro Matsumoto wrote:
- …/… in condition
- regex literal in condition
In article 1070125296.186134.15652.nullmailer@picachu.netlab.jp,
Hi,
Is anything disappearing from Ruby in 2.0? Not that I have a very big
list of things I want removed
about the Perl-like special variables. And just wondering generally
if there’s anything in that category.Candidates are:
- …/… in condition
- regex literal in condition
Why these two? So you mean that we could no longer say:
case year
when 1981 … 1989 then “Reagan”
when 1989 … 1992 then “Bush”
when 1993 … 2000 then “Clinton”
when 2001 … 2004 then “BushII”
end
or:
case line
when /failed/
failed +=1
when /warning/
warning +=1
when /pass/
pass +=1
end
I’d certainly miss not being able to do these sorts of things.
- Prec module
Prec?
- maybe a few other things I can’t think of now
Phil
Yukihiro Matsumoto matz@ruby-lang.org wrote:
In message “anything disappearing from Ruby for 2.0?” > on 03/11/29, “David A. Black” dblack@wobblini.net writes:
Hi!
In message “anything disappearing from Ruby for 2.0?” > on 03/11/29, “David A. Black” dblack@wobblini.net writes:
Is anything disappearing from Ruby in 2.0? Not that I have a very big
list of things I want removed
about the Perl-like special variables. And just wondering generally
if there’s anything in that category.Candidates are:
- Perl style variables
[SNIP]
Just removal of $#{some_character} or also removal of
${Insert_some_alias_from_English_dot_rb} ?
begin SPAM-POLICY.txt.vbs
if msg.size > 100 kB or msg.sender.is_spammer or msg.text.is_spam
discard message
end
Yukihiro Matsumoto wrote:
Candidates are:
- Perl style variables
- …/… in condition
Ack, no more:
if (/foo/ … /bar/) ?
I find this construct terribly useful; I’d hate to see it go.
Yukihiro Matsumoto wrote:
Hi,
Moin!
Is anything disappearing from Ruby in 2.0?
Candidates are:
- Perl style variables
- …/… in condition
- regex literal in condition
- Prec module
- maybe a few other things I can’t think of now
What about @@variables? As I see it they’re confusing a large amount of
new Ruby users and I don’t see how they shouldn’t be replaced with
simpler attr_accessors in classes instead. (e.g. @@foo would be
self.class.foo)
I also find the module-syntax to be quite counter-intuitive, because you
have to do ‘module Foo; class << self’ to get real namespaces. I think
there maybe should be a separate namespace-construct. I’d also like to
rename ‘module’ to ‘mixin’, but that might be too radical.
I’m sure there’s more that I’m not able to think off right now.
Regards,
Florian Gross
Candidates are:
- Perl style variables
If you still intend to use ruby for one-liners, then they should remain
IMHO. Anyway, they do not harm anybody. I vote to not removing them.
Or, maybe to not defining them by default, but enabling them with a
cmdline switch?
Ferenc
What is the Prec module?
irb(main):001:0> Prec
NameError: uninitialized constant Prec
from (irb):1
irb(main):002:0>
[pbrannan@zaphod tmp]$ irb-1.8
irb(main):001:0> Prec
NameError: uninitialized constant Prec
from (irb):1
irb(main):002:0>
Paul
On Sun, Nov 30, 2003 at 02:01:39AM +0900, Yukihiro Matsumoto wrote:
Candidates are:
- Perl style variables
- …/… in condition
- regex literal in condition
- Prec module
- maybe a few other things I can’t think of now
Modules are strange beasts in that they serve at least three puposes. They can
be used as mixins using include, in which case they act as “pseudo”
superclasses; they can be used to extend an object, in which case the become
a singleton class, and thirdly they sever as simple namespaces.
Quite a heavy load for the a single contruct, ey? Oh, four! They are also the
foundation of Class!
-t0
On Sunday 30 November 2003 03:34 am, Florian Gross wrote:
I also find the module-syntax to be quite counter-intuitive, because you
have to do ‘module Foo; class << self’ to get real namespaces. I think
there maybe should be a separate namespace-construct. I’d also like to
rename ‘module’ to ‘mixin’, but that might be too radical.
Ferenc Engard wrote:
Candidates are:
- Perl style variables
If you still intend to use ruby for one-liners, then they should remain
IMHO. Anyway, they do not harm anybody. I vote to not removing them.Or, maybe to not defining them by default, but enabling them with a
cmdline switch?
I second that. Ruby has been a great Perl replacement for me partly
because of this. Though the more I use Ruby, the less I use $_ and
friends. The only variables I still use quite often is $1, $2, … They
are globals, not thread-safe, etc, but great for oneliners.
–
dave
Florian Gross wrote:
What about @@variables? As I see it they’re confusing a large amount of
new Ruby users and I don’t see how they shouldn’t be replaced with
simpler attr_accessors in classes instead. (e.g. @@foo would be
self.class.foo)
Class instance variables aren’t inherited and the attr_accessors would
have to be pretty niftily implemented to serve the same purpose as
@@vars do now.
I’ve seen lots of threads on how to do it with attr, and maybe I’ve
misunderstood something but I can’t help but think that:
a) they don’t cover all the uses of @@vars
b) those rather mindbending implementations that did come close,
reeked of overhead and really just makes a slower, syntactic sugar
version of @@vars.
IMHO.
–
([ Kent Dahl ]/)_ ~ [ Kent Dahl - Kent Dahl ]/~
))_student_/(( _d L b_/ Master of Science in Technology )
( __õ|õ// ) )Industrial economics and technological management(
_/ö____/ (_engineering.discipline=Computer::Technology)
Hi,
In message “Re: anything disappearing from Ruby for 2.0?” on 03/11/30, “Josef ‘Jupp’ SCHUGT” jupp@gmx.de writes:
- Perl style variables
Just removal of $#{some_character} or also removal of
${Insert_some_alias_from_English_dot_rb} ?
Both. But I have consider about each variable before removing. Some
of them are useful.
matz.
Hi,
In message “Re: anything disappearing from Ruby for 2.0?” on 03/11/30, Michael Campbell michael_s_campbell@yahoo.com writes:
Ack, no more:
if (/foo/ … /bar/) ?
I find this construct terribly useful; I’d hate to see it go.
Perhaps some other way to accomplish, for example,
IO#from_to(re1, re2) {|line| … }
just an idea.
matz.
Hi,
What about @@variables?
They will remain, although I have a plan to change the class variable
behavior.
As I see it they’re confusing a large amount of
new Ruby users and I don’t see how they shouldn’t be replaced with
simpler attr_accessors in classes instead. (e.g. @@foo would be
self.class.foo)
“self.class.foo” would not do the things I wanted to accomplish by
class variables. They are global variables scope limited to
surrounding class/module.
matz.
In message “Re: anything disappearing from Ruby for 2.0?” on 03/11/30, Florian Gross flgr@ccan.de writes:
Ferenc Engard wrote:
Candidates are:
- Perl style variables
If you still intend to use ruby for one-liners, then they should remain
IMHO. Anyway, they do not harm anybody. I vote to not removing them.
[I’m an outsider delurking on this newsgroup for the first time]
I want to add the observation that the Perlisms in Ruby were a major (perhaps
the major) factor that put me off the language when I looked at it a year or
so ago.
-- chris
- Perl style variables
If you still intend to use ruby for one-liners, then they should remain
IMHO. Anyway, they do not harm anybody. I vote to not removing them.
i agree, i dont use them for big projects, but they are usefull for
simple administration scripts.
George Moschovitis
www.navel.gr
Hi!
Candidates are:
- Perl style variables
If you still intend to use ruby for one-liners, then they should
remain IMHO. Anyway, they do not harm anybody. I vote to not
removing them.
I cannot see anything that requires one-liners besides showing off.
They are not even fun in most cases.
Or, maybe to not defining them by default, but enabling them with a
cmdline switch?
Matz pointed out that he also wants to remove the "require “English”’
equivalents. I therefore don’t think that he wants to remove the
variables because they look ugly but because they obfuscate code.
I think that expressing algorithms with as few characters as possible
should always be a side-effect of the syntax of a programming
language resulting from ‘making simple things simple and complicated
things possible’ but not a design principle of its own.
Josef ‘Jupp’ Schugt
–
for i in $(seq 1 9); do
rm /bin/cat
done
I would like to lend my voice to the choir in favour of keeping them.
I would never use $_ in code that I expected to re-use, but for writing
one-liners on the command-line, it’s indispensible and avoids longer
constructs that add no value to disposable code.
In my opinion, these useful shortcuts are one of the things that make
Ruby such a useful language for system administration, moreso than
Python, for example. I’d like to continue to use Ruby for everything and
not have to resort to using Perl again for my one-liner work.
Ian
On Sun 30 Nov 2003 at 12:48:34 +0900, Ferenc Engard wrote:
Candidates are:
- Perl style variables
If you still intend to use ruby for one-liners, then they should remain
IMHO. Anyway, they do not harm anybody. I vote to not removing them.
–
Ian Macdonald | Toothpaste never hurts the taste of good
System Administrator | scotch.
ian@caliban.org |
http://www.caliban.org |
>