From: David Flanagan <david@...>
Date: 2007-09-12T09:25:49+09:00
Subject: Re: autoloading Fiber

I'm not trying to suggest that autoloading the fiber library is a good 
idea.  I'm pointing out that the way fiber is currently set up it cannot 
be autoloaded, and this seems like a bug.  Note that continuations can 
be autoloaded in 1.9

	David

Charles Oliver Nutter wrote:
> David Flanagan wrote:
>> In order to use the new Fiber class in 1.9, we have to require 
>> 'fiber'.  The fiber functionality is actually built into the core (so 
>> it can be used for external iterators) but in order to get at the API 
>> for using it in Ruby, we have to require 'fiber'. Ko1 says that this 
>> is for safety reasons.  (The same goes for continuations in Ruby 1.9: 
>> you must explictly require them if you want to use them.)
>>
>> Someone (I forget who) on this list pointed out that the Fiber class 
>> itself is defined by default, but that the methods of the class are 
>> not.  I don't understand why this is, and I've just realized that it 
>> causes problems with autoload:
>>
>> autoload :Fiber, "fiber"
>>
>> This won't work. Since Fiber is already defined, the "fiber" module 
>> will never be autoloaded...  (Unless ko1 thinks that fibers are so 
>> unsafe we should not be allowed to autoload them? :-)
>>
>> Maybe I'm missing something, but I don't see any code that depends on 
>> the Fiber constant being defined before any of its methods are, so I'm 
>> wondering if the patch below wouldn't be okay.  I've barely tested it, 
>> but it makes autoload work and it doesn't seem to interfere with 
>> external iterators.
> 
> I'd recommend against making Fiber autoload, since some implementations 
> may not be able to provide it. If Fiber autoloads, those impls may 
> instead get a const missing error...that could happen anywhere Fiber is 
> referenced, and you wouldn't be able to know where. Having scripts do an 
> explicit require would ensure you can respond to fibers not being 
> present, since you'd know at require time they aren't available.
> 
> There's also the split between "safe" and "unsafe" Fiber features, which 
> it seems would be better served by having explicit requires.
> 
> - Charlie
>