[ruby-core:39845] Re: Discussion results

(10/02/2011 01:36 PM), Intransition wrote:
> I did not have the fortune of attending the discussion, but I would
> like to put forth some notions I've had/seen for Ruby 2.0:
> 
> 1) Go through ActiveSupport core extensions and Ruby Facets to find
> most popular and useful methods and port them over. Good examples are
> String #indent, #tab, #tabto, #to_h/#to_hash methods, Hash#rekey,
> #blank, those have been useful to me. I'm sure others have their own
> favorites too --take a poll or do some code analysis to figure out
> which ones.

Are you asking this for us?  Then sorry.  Please consider going through
by yourself.  And propose us a specific portion.  For instance, someone
else had already opened blank? story.

http://redmine.ruby-lang.org/issues/5372

> 2) Make toplevel a self extended module instead of a weak proxy of
> Object. Besides being conceptually easier to understand, it would
> allow DSL scripts to run at toplevel without worry of infecting
> Object. This would have been a huge boon for me in couple of my
> projects, such as my test framework --instead I had to write my own
> toplevel-like proxy to fake it, which is inevitably imperfect and just
> pain to have to do.

No idea for this.

> 3)  Add margin literal, e.g.
> 
>     > %L|This is
>         |  margin
>         |    controlled.
>     => "This is\n  margin\n    controlled."
> 
> Nothing sucks more for readability than having to flush a literal
> string to the left margin in the middle of indented code.

Sounds interesting.

> 4) Treat `@` as a hash object, so @['foo'] is the same as @foo. This
> would make it much easier to work with instance variables, e.g.
> @.each{ |k,v| ... }

Also interesting.
 
> 5) Better support for lazy and differed processing, e.g. lazy.rb and
> denumerable.rb.

Can you show us pointers for those things?

> 6) Add High-order Function to language but more tightly integrated to
> remove inefficiencies of pure-Ruby implementation. This is great
> device for making robust fluent notations.

I like the idea in general but sounds a bit too vague.

> 7) Lastly, I think serious consideration should be given to removing
> the distinction between class and module. The distinction is purely a
> conceptual one that has built artificial limitations and undo
> complications into the language. What difference does it make to Bar
> if we include Bar, subclass Bar or instantiate Bar? Bar shouldn't have
> to care --it's just an encapsulation.

You mean we should allow multiple inheritance like the hell of C++ ?

Please no.

> Oh, how could I forget:
> 
> 8) Open up access to the internal methods for looking up scripts used
> to find files in the $LOAD_PATH. Use of this is plugin file loaders.

I think this was discussed.  Eric proposed an extension to the file-loading
protocol, and I think he'll sophisticate it more enough to be accepted.

> 9) autoload needs use an overridable require method of some sort. I
> use a custom load manager for developement, but since I can't get hold
> of autoload's require I can't use autoload in my projects, which
> majorly sucks!!!

What happens if an autoloaded file then redefine the require method?  Should
that propagate to other autoloads?  If so, that should cause a very tricky
multithreading issue that is almost impossible to debug.