"implicit class" suggestion

[Jon Pretty]

My previous answer to David's problem got me thinking: Basically, all he wanted to do was create a
new infix operator, though the amount of code required (a class and method definition plus an
implicit function definition) seemed a touch heavy, by Scala's standards.

Seeing as adding functionality to existing classes is quite a common use of implicit definitions,
could the two be combined, for example:

   implicit class RichOption[A](val v : Option[A]) {
     def ||| = ...
     ...
   }

which would simply be equivalent to:

   implicit def optToRichOpt[A](x : Option[A]) = new RichOption[A](x)
   class RichOption[A](val v : Option[A]) {
     def ||| = ...
     ...
   }

i.e. where the definition of a class (or case class) Z has a single-parameter default constructor,
it should be optionally labeled 'implicit', in which case an implicit definition should also be
created within the same scope converting from the type of Z's parameter to Z.  Furthermore, any
import of Z should also import the implicit function.

Z would thus be inseparable from its implicit conversion function.

Any thoughts?

All the best,
Jon

--
Jon Pretty | Sygneca Ltd.

[Martin Odersky]

Jon Pretty wrote:

> My previous answer to David's problem got me thinking: Basically, all
> he wanted to do was create a new infix operator, though the amount of
> code required (a class and method definition plus an implicit function
> definition) seemed a touch heavy, by Scala's standards.
>
> Seeing as adding functionality to existing classes is quite a common
> use of implicit definitions, could the two be combined, for example:
>
>   implicit class RichOption[A](val v : Option[A]) {
>     def ||| = ...
>     ...
>   }
>
> which would simply be equivalent to:
>
>   implicit def optToRichOpt[A](x : Option[A]) = new RichOption[A](x)
>   class RichOption[A](val v : Option[A]) {
>     def ||| = ...
>     ...
>   }

It's a thought. On the plus side: I avoids needless repetition and thus
makes it easier to write implicit extensions.
On the minus side: We now that implicits are problematic; sort of a
``last resort'' thing. Is it desirable to make writing them easier? I
mean, I am totally against deliberate obfuscation, but one needs to ask
the question whether
its worth to make an investment (in terms of spec complexity).

Cheers

 -- Martin
 

[sean.mcdirmid]

To throw some oil on the fire, the way implicit coercions are often  
used to extend classes (via new richer interfaces) appears similar to  
MultiJava-style open classes and some similar work on expanders  
presented at OOPSLA 2006. Implicit coercions are more than that of  
course, but perhaps this usage of implicit defs could be packaged  
into a higher-level construct that is safer to use/less verbose/less  
prone to abuse? Virtual classes provide one solution, but they  
effectively create new classes and can't be used to extend pre-
packaged library classes. My preference is to support a project-like  
(not object-like) module abstraction, where rich (non-state adding)  
extensions to classes in imported libraries could be configured  
outside of source code on a per-module basis. This could pull the  
rich-extension problem out of the Scala language and into the tool/
linking language context, where ambiguous implicit look-ups wouldn't  
be an issue. But there are drawbacks to the tool vs. language  
enhancement approach.

In general, implicits seem like a powerful/flexible but accordingly  
dangerous language construct that could be replaced (or encapsulated)  
by multiple higher-level but less general constructs. For example, I  
often use implicit parameters to emulate dynamic binding, but direct  
support for dynamic parameters would be nicer. However, many such of  
these higher-level features would probably bloat the language spec,  
and that probably wouldn't be so great.

On Jan 16, 2007, at 10:45 AM, martin odersky wrote:

> It's a thought. On the plus side: I avoids needless repetition and  
> thus makes it easier to write implicit extensions.
> On the minus side: We now that implicits are problematic; sort of a  
> ``last resort'' thing. Is it desirable to make writing them easier?  
> I mean, I am totally against deliberate obfuscation, but one needs  
> to ask the question whether
> its worth to make an investment (in terms of spec complexity).
>
> Cheers
>
> -- Martin

[Steven E. Harris]

Jon Pretty <[hidden email]> writes:

> where the definition of a class (or case class) Z has a
> single-parameter default constructor, it should be optionally
> labeled 'implicit', in which case an implicit definition should also
> be created within the same scope converting from the type of Z's
> parameter to Z.

That's more or less what C++ does with its single-argument
constructors, and one has to disable this behavior explicitly with,
appropriately enough, the keyword "explicit". Such "user-defined
conversions" may not pass through more than one implicit step.

--
Steven E. Harris