Asp Forum - Re: Typed Parameters

Trans

4/2/2006 12:36:00 AM

<blockquote>
It's not actually that practical, and such things end up making your
code very much like C++ and Java.

Ruby is smarter than that. Ruby can do more than that.

Think in terms of what your object's required capabilities are instead
of pretending that a class indicator is sufficient for that.
</blockquote>

While I understand you pointr Austin --obviously where talking Duck
Typing here. But I think it is interesting to condier that this is some
respect antithetical to OOP in general --I mean the reciever _is_ a
specific type. And that reacieve detemine the functionality of the
method call. It is sort of as if you were progamming in a more
traditional functional language and _had_ to specifiy the type of the
first argument, but never the remaining.

foofunc( FooClass foo, clever, smart, stupid )

instead of

foo.foofunc( clever, smart, stupid )

So why shouldn't any of the other participating objects have a
selective effect too?

T.

26 Answers

dblack

4/2/2006 12:57:00 AM

gabriele renzi

4/2/2006 1:06:00 AM

Trans ha scritto:
> It is sort of as if you were progamming in a more
> traditional functional language and _had_ to specifiy the type of the
> first argument, but never the remaining.
>
> foofunc( FooClass foo, clever, smart, stupid )
>
> instead of
>
> foo.foofunc( clever, smart, stupid )
>
> So why shouldn't any of the other participating objects have a
> selective effect too?

<noise type="useless">
I agree, let's stop this antidemocratic self-proclaimed dictatorship of,
well, self.
(and recall that our uncle Common Lisp had dynamic typing and multiple
dispatch for decades withouth becoming Java :)
</noise>

Daniel Nugent

4/2/2006 1:09:00 AM

Well, I think you should allowed to put a selective effect on the
remaining arguments, but it should at least allow you to be a little
smarter than simply checking one single Type. I'd like to see you
able to check against multiple types as well as methods and
combinations thereof, like

def foo(arg1 : (Array and :custom_array_method) or Hash or :special_method)

Then at least it's simply a syntactic convenience for writing
respond_to? and kind_of? calls. And, logically, you should be able to
assign these parameter checks to a variabe so you can reduce the
duplication of them, although I don't have a clue as to what a good
syntax for that would be... Maybe something like:

type_check = TypeCheck.new do |var|
case var
when Array
return true if var.respond_to? :custom_array_method
when Hash
return Hash
else
return true if var.respond_to? :special_method
end
return false
end

And, of course, you can do any checking you want in the block. You
could then do this:

def foo(arg1 : type_check)
def bar(arg1, arg2 : type_check)

On 4/1/06, Trans <transfire@gmail.com> wrote:
> <blockquote>
> It's not actually that practical, and such things end up making your
> code very much like C++ and Java.
>
> Ruby is smarter than that. Ruby can do more than that.
>
> Think in terms of what your object's required capabilities are instead
> of pretending that a class indicator is sufficient for that.
> </blockquote>
>
> While I understand you pointr Austin --obviously where talking Duck
> Typing here. But I think it is interesting to condier that this is some
> respect antithetical to OOP in general --I mean the reciever _is_ a
> specific type. And that reacieve detemine the functionality of the
> method call. It is sort of as if you were progamming in a more
> traditional functional language and _had_ to specifiy the type of the
> first argument, but never the remaining.
>
> foofunc( FooClass foo, clever, smart, stupid )
>
> instead of
>
> foo.foofunc( clever, smart, stupid )
>
> So why shouldn't any of the other participating objects have a
> selective effect too?
>
> T.
>
>
>

--
-Dan Nugent

Don't Feel Like Typing? Send me a voicemail:
http://odeo.com/sendmeamessage...

Daniel Nugent

4/2/2006 1:14:00 AM

Actually... now that I'm looking about it, that's kinda dumb, we might
as well just add pre, post, and around calls so we can more cleanly
seperate the Type and condition checks from the actual method.

On 4/1/06, Daniel Nugent <nugend@gmail.com> wrote:
> Well, I think you should allowed to put a selective effect on the
> remaining arguments, but it should at least allow you to be a little
> smarter than simply checking one single Type. I'd like to see you
> able to check against multiple types as well as methods and
> combinations thereof, like
>
> def foo(arg1 : (Array and :custom_array_method) or Hash or :special_method)
>
> Then at least it's simply a syntactic convenience for writing
> respond_to? and kind_of? calls. And, logically, you should be able to
> assign these parameter checks to a variabe so you can reduce the
> duplication of them, although I don't have a clue as to what a good
> syntax for that would be... Maybe something like:
>
> type_check = TypeCheck.new do |var|
> case var
> when Array
> return true if var.respond_to? :custom_array_method
> when Hash
> return Hash
> else
> return true if var.respond_to? :special_method
> end
> return false
> end
>
> And, of course, you can do any checking you want in the block. You
> could then do this:
>
> def foo(arg1 : type_check)
> def bar(arg1, arg2 : type_check)
>
> On 4/1/06, Trans <transfire@gmail.com> wrote:
> > <blockquote>
> > It's not actually that practical, and such things end up making your
> > code very much like C++ and Java.
> >
> > Ruby is smarter than that. Ruby can do more than that.
> >
> > Think in terms of what your object's required capabilities are instead
> > of pretending that a class indicator is sufficient for that.
> > </blockquote>
> >
> > While I understand you pointr Austin --obviously where talking Duck
> > Typing here. But I think it is interesting to condier that this is some
> > respect antithetical to OOP in general --I mean the reciever _is_ a
> > specific type. And that reacieve detemine the functionality of the
> > method call. It is sort of as if you were progamming in a more
> > traditional functional language and _had_ to specifiy the type of the
> > first argument, but never the remaining.
> >
> > foofunc( FooClass foo, clever, smart, stupid )
> >
> > instead of
> >
> > foo.foofunc( clever, smart, stupid )
> >
> > So why shouldn't any of the other participating objects have a
> > selective effect too?
> >
> > T.
> >
> >
> >
>
>
> --
> -Dan Nugent
>
> Don't Feel Like Typing? Send me a voicemail:
> http://odeo.com/sendmeamessage...
>

--
-Dan Nugent

Don't Feel Like Typing? Send me a voicemail:
http://odeo.com/sendmeamessage...

Daniel Nugent

4/2/2006 1:22:00 AM

Maybe the code for that could look something like this:

def foo(arg1, arg2)
BLAHBLAHBLAH STUFF GOES HERE
end.pre do |*args|
SOME MORE STUFF
end.post do |*result|
A LITTLE MORE
end.around do|*args, &method|
SOME
method.call(transformed_args)
STUFF
end

And then you could dynamically add and remove the pre and post
conditions or whatever.

On 4/1/06, Daniel Nugent <nugend@gmail.com> wrote:
> Actually... now that I'm looking about it, that's kinda dumb, we might
> as well just add pre, post, and around calls so we can more cleanly
> seperate the Type and condition checks from the actual method.
>
> On 4/1/06, Daniel Nugent <nugend@gmail.com> wrote:
> > Well, I think you should allowed to put a selective effect on the
> > remaining arguments, but it should at least allow you to be a little
> > smarter than simply checking one single Type. I'd like to see you
> > able to check against multiple types as well as methods and
> > combinations thereof, like
> >
> > def foo(arg1 : (Array and :custom_array_method) or Hash or :special_method)
> >
> > Then at least it's simply a syntactic convenience for writing
> > respond_to? and kind_of? calls. And, logically, you should be able to
> > assign these parameter checks to a variabe so you can reduce the
> > duplication of them, although I don't have a clue as to what a good
> > syntax for that would be... Maybe something like:
> >
> > type_check = TypeCheck.new do |var|
> > case var
> > when Array
> > return true if var.respond_to? :custom_array_method
> > when Hash
> > return Hash
> > else
> > return true if var.respond_to? :special_method
> > end
> > return false
> > end
> >
> > And, of course, you can do any checking you want in the block. You
> > could then do this:
> >
> > def foo(arg1 : type_check)
> > def bar(arg1, arg2 : type_check)
> >
> > On 4/1/06, Trans <transfire@gmail.com> wrote:
> > > <blockquote>
> > > It's not actually that practical, and such things end up making your
> > > code very much like C++ and Java.
> > >
> > > Ruby is smarter than that. Ruby can do more than that.
> > >
> > > Think in terms of what your object's required capabilities are instead
> > > of pretending that a class indicator is sufficient for that.
> > > </blockquote>
> > >
> > > While I understand you pointr Austin --obviously where talking Duck
> > > Typing here. But I think it is interesting to condier that this is some
> > > respect antithetical to OOP in general --I mean the reciever _is_ a
> > > specific type. And that reacieve detemine the functionality of the
> > > method call. It is sort of as if you were progamming in a more
> > > traditional functional language and _had_ to specifiy the type of the
> > > first argument, but never the remaining.
> > >
> > > foofunc( FooClass foo, clever, smart, stupid )
> > >
> > > instead of
> > >
> > > foo.foofunc( clever, smart, stupid )
> > >
> > > So why shouldn't any of the other participating objects have a
> > > selective effect too?
> > >
> > > T.
> > >
> > >
> > >
> >
> >
> > --
> > -Dan Nugent
> >
> > Don't Feel Like Typing? Send me a voicemail:
> > http://odeo.com/sendmeamessage...
> >
>
>
> --
> -Dan Nugent
>
> Don't Feel Like Typing? Send me a voicemail:
> http://odeo.com/sendmeamessage...
>

--
-Dan Nugent

Don't Feel Like Typing? Send me a voicemail:
http://odeo.com/sendmeamessage...

Trans

4/2/2006 1:54:00 AM

dblack@wobblini.net wrote:
> Hi --
>
> On Sun, 2 Apr 2006, Trans wrote:
>
> > <blockquote>
> > It's not actually that practical, and such things end up making your
> > code very much like C++ and Java.
> >
> > Ruby is smarter than that. Ruby can do more than that.
> >
> > Think in terms of what your object's required capabilities are instead
> > of pretending that a class indicator is sufficient for that.
> > </blockquote>
> >
> > While I understand you pointr Austin --obviously where talking Duck
> > Typing here. But I think it is interesting to condier that this is some
> > respect antithetical to OOP in general --I mean the reciever _is_ a
> > specific type. And that reacieve detemine the functionality of the
> > method call. It is sort of as if you were progamming in a more
> > traditional functional language and _had_ to specifiy the type of the
> > first argument, but never the remaining.
> >
> > foofunc( FooClass foo, clever, smart, stupid )
> >
> > instead of
> >
> > foo.foofunc( clever, smart, stupid )
>
> It's actually more like this:
>
> foofunc(object_that_responds_to_foofunc, etc.)
>
> The fact that an object handles a message does not imply its class.
> (I'm transliterating 'type' to 'class' as that seems to be what the
> thread is actually about [as it usually is :-].)

But the class of that object dictates the functionality of that
message. That's my point --it's class based. A double dispath makes
this very clear:

class String
def from( obj )
# the parameter is type String no matter what
obj.to( self )
end
end

We can even do some fancy dispatching to achieve type parameters:

class String
def cool( *args )
args.shift.cool_string( self, *args )
end
end

class Hash
def cool_string( str, *args )
args.shift.cool_string_hash( str, self )
end
end

class Boolean
def cool_string_hash( str, hsh )
p str.class, hsh.class, self.class
end
end

def cool( clever, smart, stupid )
clever.cool( smart, stupid )
end

cool( "a string", { :a=>'hash' }, Boolean.new )

produces

String
Hash
Boolean

but

cool( 1, 2, 3 ) # => NoMethodError

T.

Trans

4/2/2006 2:05:00 AM

Daniel Nugent wrote:
> Actually... now that I'm looking about it, that's kinda dumb, we might
> as well just add pre, post, and around calls so we can more cleanly
> seperate the Type and condition checks from the actual method.

No, it's not so dumb actually. A system like the one you propose could
be used for multi-dispatch --mere method wraps could not, they'd just
be a more formal way of doing what we already must do using case
statments.

I actually wrote a system much like teh one you propose called
LightType, it was based on the Euphoria language's type system. Hmm...
at the time I didn't hink of using multi-dispatch with it. Since I
recently wrote a working overload method maybe I'll revist the
possibility.

T.

Daniel Nugent

4/2/2006 2:23:00 AM

Hrm... I see, however, effective multi-dispatch would still be
possible with only around calls. Simply make the public method a
dummy:

def public_dummy(*args);end.around do |*args|
SOME_ARGUMENT_CONDITION CODE
when CONDITION 1
real_method_1
when CONDITION 2
real_method_2
else
real_method_general
end
end

And, I would say that this is perfectly acceptable because the number
of times you actually NEED multi-methods in Ruby is going to be pretty
small.

On 4/1/06, Trans <transfire@gmail.com> wrote:
>
> Daniel Nugent wrote:
> > Actually... now that I'm looking about it, that's kinda dumb, we might
> > as well just add pre, post, and around calls so we can more cleanly
> > seperate the Type and condition checks from the actual method.
>
> No, it's not so dumb actually. A system like the one you propose could
> be used for multi-dispatch --mere method wraps could not, they'd just
> be a more formal way of doing what we already must do using case
> statments.
>
> I actually wrote a system much like teh one you propose called
> LightType, it was based on the Euphoria language's type system. Hmm...
> at the time I didn't hink of using multi-dispatch with it. Since I
> recently wrote a working overload method maybe I'll revist the
> possibility.
>
> T.
>
>
>

--
-Dan Nugent

Don't Feel Like Typing? Send me a voicemail:
http://odeo.com/sendmeamessage...

Robert Dober

4/2/2006 7:03:00 AM

On 4/2/06, Daniel Nugent <nugend@gmail.com> wrote:
>
> Well, I think you should allowed to put a selective effect on the
> remaining arguments, but it should at least allow you to be a little
> smarter than simply checking one single Type. I'd like to see you
> able to check against multiple types as well as methods and
> combinations thereof, like
>
> def foo(arg1 : (Array and :custom_array_method) or Hash or
> :special_method)
>
> Then at least it's simply a syntactic convenience for writing
> respond_to? and kind_of? calls. And, logically, you should be able to
> assign these parameter checks to a variabe so you can reduce the
> duplication of them, although I don't have a clue as to what a good
> syntax for that would be... Maybe something like:
>
> type_check = TypeCheck.new do |var|
> case var
> when Array
> return true if var.respond_to? :custom_array_method
> when Hash
> return Hash
> else
> return true if var.respond_to? :special_method
> end
> return false
> end
>
> And, of course, you can do any checking you want in the block. You
> could then do this:
>
> def foo(arg1 : type_check)
> def bar(arg1, arg2 : type_check)
>
> On 4/1/06, Trans <transfire@gmail.com> wrote:
> > <blockquote>
> > It's not actually that practical, and such things end up making your
> > code very much like C++ and Java.
> >
> > Ruby is smarter than that. Ruby can do more than that.
> >
> > Think in terms of what your object's required capabilities are instead
> > of pretending that a class indicator is sufficient for that.
> > </blockquote>
> >
> > While I understand you pointr Austin --obviously where talking Duck
> > Typing here. But I think it is interesting to condier that this is some
> > respect antithetical to OOP in general --I mean the reciever _is_ a
> > specific type. And that reacieve detemine the functionality of the
> > method call. It is sort of as if you were progamming in a more
> > traditional functional language and _had_ to specifiy the type of the
> > first argument, but never the remaining.
> >
> > foofunc( FooClass foo, clever, smart, stupid )
> >
> > instead of
> >
> > foo.foofunc( clever, smart, stupid )
> >
> > So why shouldn't any of the other participating objects have a
> > selective effect too?
> >
> > T.
> >
> >
> >

I quite agree, showes my how helpless I braught this up. :-(
Should have named the thread "Easier ways to enforce contracts".
Is that not strange that we think types immediately and than are afraid of
ancient Computer Science History.

Now there is another point.

My programs often pass objects of an unexpected "contract, behavior, type,
mixin interface" you name it.
I would like a modern language to help me, the *stupid* programmer to be
more *effective*
Ruby claims that.

So let me suggest the following syntax

def foo (bar, foobar) is a shortcut to
def foo( bar, foobar : Object) which is a shortcut to
def foo( bar, foobar : { |para| Object === para } ) so we can put any
constraint in there.

I still think that is a good thing for readability and maintenance and
*nobody* would be forced to use it.
Furthermore we are not forced to use the block inside the formal parameter
list, it would just give us the opportunity.

I really fail to see why this is inhibiting the language.
Such programs fail explicitly and early, which is better (I claim) than
maybe failing later or just not behaving as expected.

Robert

--
> -Dan Nugent
>
> Don't Feel Like Typing? Send me a voicemail:
> http://odeo.com/sendmeamessage...
>
>

--
Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein

gabriele renzi

4/2/2006 11:40:00 AM

Daniel Nugent ha scritto:

> And, I would say that this is perfectly acceptable because the number
> of times you actually NEED multi-methods in Ruby is going to be pretty
> small.

care to elaborate?

I don't think you're saying that we can't do things withouth
multimethods, but just in case, a cpu with only
SUBTRACT_AND_BRANCH_IF_NEGATIVE is perfectly fine to do everything, but
this does not make it pleasant.

comp.lang.ruby

Re: Typed Parameters

Trans

dblack

gabriele renzi

Daniel Nugent

Daniel Nugent

Daniel Nugent

Trans

Trans

Daniel Nugent

Robert Dober

gabriele renzi

x Login to ForumsZone