Re: RUBY_IMPLEMENTATION

On 4 Apr 2008, at 23:23, Luis Lavena wrote:
> On Fri, Apr 4, 2008 at 7:13 PM, Eleanor McHugh
> <[e-mail]> wrote:
>>
>> I think this over-complicates matters. Why not use something along  
>> the
>> lines of:
>>
>> FEATURES.includes?(:windows_vista)
>> FEATURES.includes?(:fork, :c_extensions)
>>
>>
>
> I agree that FeatureSet:: can be too verbose and can get a bit messy
> over time, but :windows_vista don't tell me nothing, :fork alone
> neither.

Well it tells you whether or not the current running system claims to  
do things you'd expect on Windows Vista, or can perform fork(). It's a  
convention, and any implementation or library or extension can then  
insert symbols into the FEATURES set that it wants programs to be able  
to provide workarounds for when they're absent.

> Again, I think we are going beyond the idea of matz about
> RUBY_IMPLEMENTATION or RUBY_ENGINE functionality and dealing with
> something that should be taked in consideration in core and not by
> extended features like this.

I don't disagree with having RUBY_IMPLEMENTATION or whatever, but it's  
a very static way of coping with a problem that's effectively  
unbounded - checking to see if a desired feature is present and then  
allowing elegant fallbacks for when it isn't. Taken further FEATURES  
could even be a Hash with the features as keys and the version number/ 
type as values, such that

FEATURES.includes?(:microsoft_windows)	# is this a windows platform
FEATURES[:microsoft_windows]			# might return 98 or :vista
FEATURES[:my_custom_extension]		# might return 1.0

Obviously this idea needs work but it would be a neat facility to have  
when aiming for multi-platform support.

> Example: fork shouldn't be available / defined on platforms it doesn't
> support, but instead it just raises an exception on Windows.

Which of course is another way of achieving the same thing.

if FEATURES.includes?(:microsoft_windows) then
	# whatever fallback action
else
	begin
		fork(...)
	rescue Exception => e
	end
end

is equivalent to

begin
	fork(...)
rescue appropriate_exception_on_windows
rescue Exception => e
end

For what it's worth I prefer the second form for this particular case,  
but I know lots of Ruby developers who find heavy use of exception  
handling more difficult to follow than if...then...else constructs.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason