[ruby-core:39846] Re: 2.0 feature questionnaire

On Sun, Oct 2, 2011 at 1:30 AM, Yukihiro Matsumoto <[e-mail]> wro=
te:
> In message "Re: [ruby-core:39822] Re: 2.0 feature questionnaire"
> =A0 =A0on Sun, 2 Oct 2011 15:45:29 +0900, Jeremy Kemper <jeremy@bitsweat.=
net> writes:
> |2. Refinements. @shugo's proposal.
>
> Current reference implementation slows down everything from 5-15%,
> that is not acceptable. =A0Unless we come up with good implementation,
> we have to wait until further future.

Have you considered adding it despite the performance penalty?

Many Ruby users would accept a 15% slowdown as a reasonable price for
a valuable new feature.

Performance can be improved at any time, even in point releases. But
the language must wait years (3.0) until reconsidering a large change.

Refinements will improve every Rubyist's experience. It will change
the way libraries are written. By postponing the feature, we lose
these benefits. I think it's more valuable than runtime speed.

(I know the decision is difficult!)

> |3. MVM, with inter-vm message passing.
>
> I have not decided yet, but since MVM requires incompatible changes to
> C API, so we might pend it to Ruby 3.0.

I understand @shyouhei's branch is backward compatible for extensions
that don't use MVM features.

I think it's another case where the benefits outweigh the cost.

C extensions can gradually update for MVM compatibility.

Otherwise, we wait for Ruby 3.0 and we confront the same problem. Then
we pend it to Ruby 4.0 for the same reason, because it requires
incompatible changes to the C API.

> |4. Fast, native debugger. We have ruby-debug19, but it relies on
> |internal headers and API so it's hard to build and often broken.
>
> We are discussing adding more probes, such as DTrace. These probes
> would allow us to implement efficient debugger.

That's good news! However, ruby-debug is efficient. The problem is how
to maintain it as a "first class" extension, since it relies on Ruby
internals.

I hope the solution is to include it with Ruby.

> |5. Easy module dependencies and a hook for "included in a class."
> |Nesting modules to build up behavior could be friendlier and more
> |concise.
>
> |# Concise form:
> |module A
> | =A0class_included { print 'A' }
> |end
>
> This is new and interesting idea. =A0Let us consider it.

Thank you for considering it. I think it would improve the design and
modularity of many Ruby libraries. As a real-world example, it made
Rails 3 easier to understand, easier to test, and more modular.

Jeremy