1.9 Backport?

Reading:
  http://www.ruby-lang.org/en/news/2006/10/26/rubyconf-2006-recap/

If Ruby 1.9+ won't be released for over a year, can we backport a few
features? Most noteabley #instance_exec and the ability of a block to
take a &block argument --the lack of these exact a heavy toll on good
clean metacode.

Also, is it true RCRchive is to be no more?

Thanks,
T.

Reading:
  RubyConf 2006 Recap
If Ruby 1.9+ won't be released for over a year, can we backport a few
features? Most noteabley #instance_exec and the ability of a block to
take a &block argument --the lack of these exact a heavy toll on good
clean metacode.

Probably not. Ruby 1.8 is supposed to be *stable*, and I doubt that
there'll be a shim like there was for Ruby 1.6 to 1.8, either.

Also, is it true RCRchive is to be no more?

No. Take a look at my blog; RCRchive is going to change focus into
probably being a starting point for discussion, but *how* such entries
are processed will probably change from the current software to
something else that allows for mailing-list discussions.

-austin

···

On 10/26/06, Trans <transfire@gmail.com> wrote:
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

Trans wrote:

Reading:
  http://www.ruby-lang.org/en/news/2006/10/26/rubyconf-2006-recap/

Also, is it true RCRchive is to be no more?

No.

RCRchive is to be remade. Most RCRs will be tossed
because new RCRs are required to explain the *WHY*
behind the proposed change and come replete with tests
and sample implementations. (Most current RCRs don't
satisfy these criteria.)

See Matz's keynote,

  http://www.travelistic.com/video/show/985

beginning with bikeshed at 7:30.

Later,

···

--
Bil Kleb
http://kleb.tadalist.com/lists/public/427170

Sorry, that was sloppy explaining on my part. I've tried to clean it up.

James Edward Gray II

···

On Oct 26, 2006, at 8:10 AM, Bil Kleb wrote:

Trans wrote:

Reading:
  RubyConf 2006 Recap
Also, is it true RCRchive is to be no more?

No.

RCRchive is to be remade.

Hi --

Trans wrote:

Reading:
  RubyConf 2006 Recap

Also, is it true RCRchive is to be no more?

No.

In fact, I'm hard at work on the new RCRchive. Stay tuned. It's
going to operate somewhat differently, and will be focused on 1.9/2.0
changes.

RCRchive is to be remade. Most RCRs will be tossed
because new RCRs are required to explain the *WHY*
behind the proposed change and come replete with tests
and sample implementations. (Most current RCRs don't
satisfy these criteria.)

Mind you, they're supposed to :slight_smile: It's always been a requirement that
proposals include Abstract, Problem, Analysis, and Implementation --
lots of "why", etc. Most RCRs are done conscientiously and
diligently, but some are not very complete. Hopefully the new
logistics of the process will encourage more consistent compliance.

David

···

On Thu, 26 Oct 2006, Bil Kleb wrote:

--
                   David A. Black | dblack@wobblini.net
Author of "Ruby for Rails" [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] Ruby for Rails | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org

Austin Ziegler wrote:

···

On 10/26/06, Trans <transfire@gmail.com> wrote:
> Reading:
> RubyConf 2006 Recap
> If Ruby 1.9+ won't be released for over a year, can we backport a few
> features? Most noteabley #instance_exec and the ability of a block to
> take a &block argument --the lack of these exact a heavy toll on good
> clean metacode.

Probably not. Ruby 1.8 is supposed to be *stable*, and I doubt that
there'll be a shim like there was for Ruby 1.6 to 1.8, either.

Right. I realize. I was just hoping that a few significant features
that are pure "superset" could make it back.

T.

I sympathize, but I read something about the Denver Summit (posted on
RedHanded by Daigo) indicating that absolutely no new features will be
added to Ruby 1.8. Just bug fixes.

-austin

···

On 10/26/06, Trans <transfire@gmail.com> wrote:

Austin Ziegler wrote:
> On 10/26/06, Trans <transfire@gmail.com> wrote:
> > Reading:
> > RubyConf 2006 Recap
> > If Ruby 1.9+ won't be released for over a year, can we backport a few
> > features? Most noteabley #instance_exec and the ability of a block to
> > take a &block argument --the lack of these exact a heavy toll on good
> > clean metacode.
> Probably not. Ruby 1.8 is supposed to be *stable*, and I doubt that
> there'll be a shim like there was for Ruby 1.6 to 1.8, either.
Right. I realize. I was just hoping that a few significant features
that are pure "superset" could make it back.

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

Cool. Let's just make sure that the old ones don't get "tossed', as
I'm sure there'll be some historical value in them.

Thanks,
Keith

···

On 10/26/06, dblack@wobblini.net <dblack@wobblini.net> wrote:

Hi --

On Thu, 26 Oct 2006, Bil Kleb wrote:

> Trans wrote:
>> Reading:
>> RubyConf 2006 Recap
>>
>> Also, is it true RCRchive is to be no more?
>
> No.

In fact, I'm hard at work on the new RCRchive. Stay tuned. It's
going to operate somewhat differently, and will be focused on 1.9/2.0
changes.

I sympathize, but I read something about the Denver Summit (posted on
RedHanded by Daigo) indicating that absolutely no new features will be
added to Ruby 1.8. Just bug fixes.

In the roundtable there was a specific question about backporting some
functionality. I don't recall the functionality that was being
discussed, but I clearly remember Matz indicating that he would be
willing to backport functionality if it had no impact on the current
code. The specific item being discussed wouldn't have, and he said he
would be open to looking at it.

Michael