Comments on: Implicit Conversions: More Powerful than Dynamic Typing?

By: jmalcolm

jmalcolm — Tue, 27 Jul 2010 19:25:59 +0000

I believe that the proposed Java extension methods are indeed similar to the C# equivalent that exists today. However, unless I missed something, I would think that extension methods are much more akin to method implementations in traits than to implicit type conversions.

Both features can play well together of course.

By: Reg Braithwaite

Reg Braithwaite — Thu, 02 Oct 2008 14:18:12 +0000

“I don’t particularly like defining methods using define_method and a block (it’s a memory leak waiting to happen)” => Funny thing, I have some issues with it as well, but from time to time I think about a hypothetical language called “R” where “R is to Ruby as Scheme is to Common Lisp.”

In R, all blocks are full closures and that’s also the only way to define a method, no messy three and four ways to do the same thing

By: Daniel Spiewak

Daniel Spiewak — Thu, 02 Oct 2008 01:41:32 +0000

Interesting, I wasn’t aware that you could capture a method reference in that fashion. It certainly does solve the problem of name collision. I don’t particularly like defining methods using define_method and a block (it’s a memory leak waiting to happen), but it makes sense here and I can’t think of any horrendous consequences. Thanks for the heads up!

By: Reg Braithwaite

Reg Braithwaite — Thu, 02 Oct 2008 00:03:35 +0000

If you google “ruby alias,” the very first hit is:

http://blog.jayfields.com/2006/12/ruby-alias-method-alternative.html

Which addresses the mess that is unhygienic method aliasing in a manner that is isomorphic to a very old way to deal with variable captures in Lisp macros. And quite honestly, there are other things you can do to solve the problem you are posing in a Rubyesque way without rewriting (although for some reason rewriting comes to my mind).

But I think there’s an interesting point you are making about implicit conversions, so I really don’t want to go too far down the road of debating what I would do in Ruby if I wanted to accomplish the same thing. I am a fan of static typing for enforcing domain constraints on programs, and some of these metaprogramming-like concepts are delightful to explore.

By: Daniel Spiewak

Daniel Spiewak — Wed, 01 Oct 2008 16:47:32 +0000

@Reg

I spent some time Googling, and I’m afraid I still don’t know what you mean by “several far superior ways”. I am of course aware of ParseTree, but I wanted to show the problems with such overriding without tapping the power of rewritable S-expressions. I am truly unaware of any substantively different method for accomplishing the Fixnum < override.

I will agree that it is a poor example of Ruby though. I deliberately went after an example which had type-dependent behavior. Ruby is *never* going to behave as nicely as a static language in that case.

By: Reg Braithwaite

Reg Braithwaite — Wed, 01 Oct 2008 12:04:41 +0000

A good read, thank you. That being said, your Ruby example is not representative of how to go about overriding or extending methods. I would go so far as to say it is a very poor example of Ruby metaprogramming ,period. These comments are not the place for code examples, but if you care to google the subject for a few minutes, you will come up with several far superior ways solve this problem in Ruby.

Still an interesting point about the benefits of static analysis, though.

By: Daniel Spiewak

Daniel Spiewak — Wed, 24 Sep 2008 17:11:18 +0000

@David

I wanted to provide a link right in the article, but I couldn’t find it. Seriously, I spent a good two hours Googling around to no avail.

By: David Gates

David Gates — Wed, 24 Sep 2008 12:02:47 +0000

“One of the most surprising things I’ve ever read about Scala came in the form of a (mostly positive) review article.”

Could we get a link to said article?

By: Jim McBeath

Jim McBeath — Thu, 18 Sep 2008 01:39:48 +0000

I think one of the key points, which you did not quite explicitly state, is that you can precisely control the scope of implicit conversions in Scala. Thus if you are creating an implicit conversion which could potentially cause problems in code not expecting it, such as your unusual less-than example, you can define the implicit conversions in (or import them into) only the class or block of code where you need them.

By: Michael Nischt

Michael Nischt — Tue, 16 Sep 2008 16:53:45 +0000

ok, I’m not able to post code so please have a look at the areEqual method and see why I dislike Scala’s implicit conversions:

http://gestalt.monoid.net/stuffu/ImplicitOrdered.scala

The problem is that a conversion takes place if and only if a matching method is not present. However in some cases it should convert, if the target type of the conversion has a matching method (even if the other has too).