Asp Forum - Duck Typing - comp.lang.ruby

Jim Weirich

9/13/2003 12:23:00 AM

In the Method Redefinition thread, this explanation of Duck Typing is
offered ...

> What Duck typing is based mostly on realising what sort of operations
> you want to do with the object and testing for those operations,
> rather than testing for the class. As Dave is fond of saying: type and
> class aren't the same.

This is slightly different than my understanding of Duck Typing. I
would phrase it more like this:

Duck typing is based mostly on realising what sort of operations
you want to do with the object and just doing them, rather than
worrying if the object inherits from the proper base class or
interface.

I've heard others also explain duck typing in terms of explicitly
testing for particular methods and I feel that leaves the wrong
impression. If we say Ruby supports duck typing, then newcomers are
left with the impression that you need to do a lot of testing for
particular methods (which you don't).

I would call this an example of Duck Typing ...

class Dog
def talk
puts "Woof"
end
end
class Duck
def talk
puts "Quack"
end
end
[Dog.new, Duck.new].each { |a| a.talk }

... even though there is no explicit method testing going on. After
all, if it walks and talks like a duck ...

So, am I off base?

--
-- Jim Weirich jweirich@one.net http://onest...
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

5 Answers

Gavin Sinclair

9/13/2003 12:51:00 AM

On Saturday, September 13, 2003, 10:23:16 AM, Jim wrote:

> [...]

> I would call this an example of Duck Typing ...

> class Dog
> def talk
> puts "Woof"
> end
> end
> class Duck
> def talk
> puts "Quack"
> end
> end
> [Dog.new, Duck.new].each { |a| a.talk }

> ... even though there is no explicit method testing going on. After
> all, if it walks and talks like a duck ...

> So, am I off base?

Not AFAIC. Testing for methods is one of those things that can sound
important in theory, but who ever programs like that? After all, if
the method you''re after isn''t supported, what are you going to do?
Choose another one? ;)

Of course, in frameworks and libraries there is often some funny
meta-programming going on, but that''s a special case, and it still
runs on the old assumption that you''re confident of what the code is
doing.

Gavin

Jason Creighton

9/13/2003 3:12:00 PM

On Sat, 13 Sep 2003 09:23:16 +0900
Jim Weirich <jweirich@one.net> wrote:

> In the Method Redefinition thread, this explanation of Duck Typing is
> offered ...
>
> > What Duck typing is based mostly on realising what sort of operations
> > you want to do with the object and testing for those operations,
> > rather than testing for the class. As Dave is fond of saying: type and
> > class aren''t the same.
>
> This is slightly different than my understanding of Duck Typing. I
> would phrase it more like this:
>
> Duck typing is based mostly on realising what sort of operations
> you want to do with the object and just doing them, rather than
> worrying if the object inherits from the proper base class or
> interface.
>
> I''ve heard others also explain duck typing in terms of explicitly
> testing for particular methods and I feel that leaves the wrong
> impression. If we say Ruby supports duck typing, then newcomers are
> left with the impression that you need to do a lot of testing for
> particular methods (which you don''t).

I agree completely.

> I would call this an example of Duck Typing ...
>
> class Dog
> def talk
> puts "Woof"
> end
> end
> class Duck
> def talk
> puts "Quack"
> end
> end
> [Dog.new, Duck.new].each { |a| a.talk }
>
> .. even though there is no explicit method testing going on. After
> all, if it walks and talks like a duck ...
>
> So, am I off base?

No. That is how I think of Duck Typing as well. Just call the methods.
Don''t bother with method existence checking, Ruby does it for you. (By
raising NoMethodError)

Jason Creighton

Henon

9/13/2003 11:48:00 PM

On Sat, 13 Sep 2003 09:51:29 +0900, Gavin Sinclair
<gsinclair@soyabean.com.au> wrote:

[...]
>
> Not AFAIC.

[...]

AWGTHTGTATA
Are We Going To Have To Go Through All This Again?

LOL
--
- Henon

Miha Markic

4/8/2009 7:06:00 AM

"Mark" <mmodrall@nospam.nospam> wrote in message
news:832069BC-36FC-42D0-B8B1-FCC9DC23A351@microsoft.com...
> It's not .net that has the problem with the accents but apparently it is
> the
> ado.net infrastructure that has problems serializing literals.
>
> Connecting to the db with Management Studio, I can see the connection
> properties indicate the connection has a latin1 collation. Kind of apples
> and oranges, I know but I didn't see any properties on the SqlConnection
> object to set the transfer collation. In the past I've worked with the
> MySql
> .net classes and they did expose that if I recall correctly.

Not sure about this.

>
> In terms of our existing code base and bringing everything into line, the
> big problem with using parameters is that SqlClient doesn't support
> positional parameters, like Odbc. So either I have to convert all the
> uses
> over to odbc (a substantial effort) or go find all the sprocs
> corresponding
> to all of the calls in the code, figure out what all the parameter names
> are,
> and rework all the query calls to name the parameters explicitly (also a
> significant effort).

So you are willing to be open to sql injection attacks? Good luck with that,
I hope you don't work for military ;-)

Anyway, converting to paramterized commands shouldn't be that difficult -
you may combine template based code generation (i.e. CodeSmith) with some
runtime helper methods and do much of the process automatic.

> I was hoping there would be some control over the transfer encoding
> somewhere to get the literals handled properly.

Perhaps somebody else will...
--
Miha Markic [MVP C#, INETA Country Leader for Slovenia]
RightHand .NET consulting & development www.rthand.com
Blog: blog.rthand.com

Mark

4/8/2009 1:59:00 PM

As I said, I inherited a huge codebase of already-written sprocs and calls.
The belief here is that since pretty much all the calls are to sprocs that
sql injection is not an issue.

The annoyance in conversion, as I said, is that I either have to switch
everything over to odbc, where I can have positional parameters, or I have to
go dig up the sproc for every single call to get the parameters named
properly. When there are hundreds of calls and sprocs, that's a clerical
headache.

And I am still puzzled why ado.net doesn't a) serialize literals better
and/or b) doesn't expose some way to control the transfer encoding.

MySql allows you to specify the connection/transfer encoding in the
connection string.

Thanks
Mark

"Miha Markic" wrote:

>
>
> "Mark" <mmodrall@nospam.nospam> wrote in message
> news:832069BC-36FC-42D0-B8B1-FCC9DC23A351@microsoft.com...
> > It's not .net that has the problem with the accents but apparently it is
> > the
> > ado.net infrastructure that has problems serializing literals.
> >
> > Connecting to the db with Management Studio, I can see the connection
> > properties indicate the connection has a latin1 collation. Kind of apples
> > and oranges, I know but I didn't see any properties on the SqlConnection
> > object to set the transfer collation. In the past I've worked with the
> > MySql
> > .net classes and they did expose that if I recall correctly.
>
> Not sure about this.
>
> >
> > In terms of our existing code base and bringing everything into line, the
> > big problem with using parameters is that SqlClient doesn't support
> > positional parameters, like Odbc. So either I have to convert all the
> > uses
> > over to odbc (a substantial effort) or go find all the sprocs
> > corresponding
> > to all of the calls in the code, figure out what all the parameter names
> > are,
> > and rework all the query calls to name the parameters explicitly (also a
> > significant effort).
>
> So you are willing to be open to sql injection attacks? Good luck with that,
> I hope you don't work for military ;-)
>
> Anyway, converting to paramterized commands shouldn't be that difficult -
> you may combine template based code generation (i.e. CodeSmith) with some
> runtime helper methods and do much of the process automatic.
>
> > I was hoping there would be some control over the transfer encoding
> > somewhere to get the literals handled properly.
>
> Perhaps somebody else will...
> --
> Miha Markic [MVP C#, INETA Country Leader for Slovenia]
> RightHand .NET consulting & development www.rthand.com
> Blog: blog.rthand.com
>
>

comp.lang.ruby