[#16113] Strange idea... exporting from a scope — "Hal E. Fulton" <hal9000@...>

Hello...

33 messages 2001/06/01

[#16364] Re: Garbage Collection? — Michael Davis <mdavis@...>

Windows 2000 and linux (RedHat 6.2). I have run these tests on both OSs.

12 messages 2001/06/09

[#16400] Symbolic Computation III — Mathieu Bouchard <matju@...>

14 messages 2001/06/11

[#16502] Playing with Ruby Syntax (was: Initial thoughts about Ruby From a Smalltalk Programmer) — jweirich@...

Michael> Hi Everyone, I have to say I'm utterly fascinated by Ruby

9 messages 2001/06/15

[#16661] Problem running irb with Ruby 1.6.4 under FreeBSD 4.0 — Bob Alexander <balexander@...>

I've installed Ruby 1.6.4 on a FreeBSD 4.0 machine, and get the

11 messages 2001/06/20

[#16686] opening db files made by apache dbmmanage — Fritz Heinrichmeyer <fritz.heinrichmeyer@...>

14 messages 2001/06/21

[#16801] rb_define_class() vs Class.new() — Kero van Gelder <kero@...4050.upc-d.chello.nl>

Hi,

18 messages 2001/06/23
[#16802] Re: rb_define_class() vs Class.new() — ts <decoux@...> 2001/06/23

>>>>> "K" == Kero van Gelder <kero@d4050.upc-d.chello.nl> writes:

[#16841] RE: national characters is strings — "Aleksei Guzev" <aleksei.guzev@...>

Next week I'll try to rebuild Ruby with Unicode strings. But it would be

15 messages 2001/06/25
[#16842] Re: national characters is strings — matz@... (Yukihiro Matsumoto) 2001/06/25

Hi,

[#16843] Re: national characters is strings — "Aleksei Guzev" <aleksei.guzev@...> 2001/06/25

That's good enough. But I'm afraid this could ( not would ) cause string

[#16868] Something strange with Ruby's inheritance mechanism — Eric Jacoboni <jaco@...>

As Ruby beginner, i try some "canonical" OO scripts. Doing so, I've

14 messages 2001/06/25
[#16873] RE: Something strange with Ruby's inheritance mechanism — "Aleksei Guzev" <aleksei.guzev@...> 2001/06/26

[#16879] Re: Something strange with Ruby's inheritance mechanism — Mathieu Bouchard <matju@...> 2001/06/26

On Tue, 26 Jun 2001, Aleksei Guzev wrote:

[#16869] Something strange with Ruby's inheritance mechanism — Eric Jacoboni <jaco@...>

As Ruby beginner, i try some "canonical" OO scripts. Doing so, I've

12 messages 2001/06/25

[#16881] — "Aleksei Guzev" <aleksei.guzev@...>

32 messages 2001/06/26
[#16916] Re: Method overloading (option) Was: Re: — "Wayne Blair" <wayne.blair@...> 2001/06/26

[#16920] Re: Method overloading (option) Was: Re: — matz@... (Yukihiro Matsumoto) 2001/06/26

Hi,

[#16888] finalizers, destructors and whatnot — "David Leal" <david@...>

Hi all,

16 messages 2001/06/26

[#17037] keeping an Exception object alive — David Alan Black <dblack@...>

Hello --

19 messages 2001/06/28
[#17055] Re: keeping an Exception object alive — matz@... (Yukihiro Matsumoto) 2001/06/29

Hi,

[#17066] RCR: Exception methods (was: Re: Re: keeping an Exception object alive) — David Alan Black <dblack@...> 2001/06/29

Hello --

[#17076] Re: RCR: Exception methods (was: Re: Re: keeping an Exception object alive) — matz@... (Yukihiro Matsumoto) 2001/06/29

Hi,

[#17079] Re: RCR: Exception methods (was: Re: Re: keeping an Exception object alive) — David Alan Black <dblack@...> 2001/06/29

Hello --

[#17138] Re: RCR: Exception methods (was: Re: Re: keeping an Exception object alive) — matz@... (Yukihiro Matsumoto) 2001/07/02

Hi,

[#17141] Re: RCR: Exception methods (was: Re: Re: keeping an Exception object alive) — David Alan Black <dblack@...> 2001/07/02

Hello --

[#17142] Re: RCR: Exception methods (was: Re: Re: keeping an Exception object alive) — ts <decoux@...> 2001/07/02

>>>>> "D" == David Alan Black <dblack@candle.superlink.net> writes:

[ruby-talk:16930] Re: Method overloading (option) Was: Re:

From: Mathieu Bouchard <matju@...>
Date: 2001-06-26 19:49:20 UTC
List: ruby-talk #16930
On Wed, 27 Jun 2001, Yukihiro Matsumoto wrote:

> I admint explicit dispatch based on type often comes first to mind.
> But I think things go better if we design programs based on protocols
> (i.e. based on set of methods that objects can respond).

As I may have said before, you can make protocols correspond to empty
modules, and consider inclusion of such a module Foo as a declaration of
intent: "this class is supposed to be supporting the Foo protocol".

In addition, I use the notation FooP to say "the Foo protocol (by
opposition to: the Foo implementation)", in cases where you begin by a
class ("Array") and you extract a protocol from it ("ArrayP") so that
you can check for Array-emulator classes easily. (this is in MetaRuby 0.7)



On Wed, 27 Jun 2001, Yukihiro Matsumoto wrote:

> |So if it (i.e. Guy's implementation) doesn't make too much overhead (if
> at all) and too much integration problems I would suggest to open up a
> RCR, so that everybody could give his opinion.
> It's OK for me to open up new RCR.  But to tell the truth, I feel like
> that explicit dipatch based on type is not a Ruby-way(TM).  You don't
> have to give it up though.

Allowing several concurrently existing defs for the same name causes a
problem, as a single method of class can no longer always be referred to
by a single symbol.

So, I propose that the proposal be changed such that it is a single method
definition, but with multiple bodies. This could be like:

class Array
	def [] (Integer i)
		# fetch single element
	ordef (Integer i, Integer n)
		# fetch sequence by length
	ordef (Range r)
		# fetch sequence by range
	end
end

but introducing two new big features, type checking and multipart methods,
with both an impact on the syntax and interpreter, may be too much at
once. 

maybe we can start with something like this:

class TypeList
	class<<self; alias [] new; end
	def initialize(*list) @list = list end
	def ===(args)
		return false if not @list.length == args.length
		@list.length.times {|i|
			return false if not @list[i] === args[i]
		}
		return true
	end
end

class Blahray
	def [] (*args); case args
	when TypeList[Integer]; i,=args
		# fetch single element
	when TypeList[Integer,Integer]; i,n=args
		# fetch sequence by length
	when TypeList[Range]; r=args
		# fetch sequence by range
	else
		raise TypeError, "it's your fault"
	end end
end

or maybe people would prefer:

class Array
	def matching(*types)
		return false if not length == types.length
		length.times {|i|
			return false if not types[i] === self[i]
		}
		yield
	end
end

class Blahray
	def [] (*args)
	args.matching(Integer) {|i,|
		# fetch single element here
		return value
	}
	args.matching(Integer,Integer) {|i,n|
		# fetch sequence by length here
		return values
	}
	args.matching(Range) {|r|
		# fetch sequence by range here
		return values
	else
	raise TypeError, "it's your fault"
	end
end

So, how ugly are those solutions? ;-)

(yes, i didn't really try them!)

matju

In This Thread