From: "Aleksi Niemelä" <aleksi.niemela@...>
Date: 2000-09-19T03:14:38+09:00
Subject: [ruby-talk:4992] Re: Perl 6 rumblings -- RFC 225 (v1) Data: S	uperpositions (fwd)

Michael dared to suggest, and was probably right:
> I don't think its quite understood *what* RFC 225 is proposing.  any()

While I can't grasp a bit what's going on with superpositions, I might add
that I'd bet there's never need for this type of RFC ([1]) for Ruby. I'm not
talking about the subject though; we might want to implement superpositions
in Ruby too. But in this case one has more freedom in Ruby than in Perl.

One can go mess around with the "features" (standard library) of the
language, and even add these kind of dull names into the Kernel (as class
methods; [2]), but there should be seldom need to change the interpreter
itself. It may be appropriate sometimes, like with DBC, allowing one to do
the trick faster, but usually there's no performance issues. This particular
case, at least on the Perl side, seem to relate to performance issues. So on
the contrary of my bold bet, the RFC might be timely for Ruby too.

In any case the fact that the language, and it's designers and creators, are
taking the future into account in such great detail is very interesting.
AFAIK, practical computers taking advantage of phenomenal phenomenon as
superpositions are not common yet.

And I hesitate to suggest, but it might be beneficial, at least for the 2.0,
to collect pile of RFFs (Requests For Features), which have been approved
from RRFCs (Ruby Requests For Comments, as I don't like different RFCs get
mixed) for implementation. That way might increase the quality of random
thoughts of random developers making their way into the major release.

I'm not sure there's any point to move hastily and take this practice for
the forecoming development of 1.8 (few days still :), as I trust it's still
relatively easy for matz to keep up to date. The things will probably change
when apparently very bright current user pool (exclude me, of course :)
explodes *much* bigger. Then such systematic approach might help matz and
other core developers to keep up to date, help communicating, and especially
encourage discussion.

	- Aleksi

[1]: "let's move this extension into the core language (interpreter) as it'd
be faster and easier to use there"-type of RFC

[2]: don't we have a bad name for class methods as Kernel is not a class,
but does still contain class methods ?)