[scala] Option vs null

[Jesper Nordenberg]

Jamie Webb wrote:
> This seems pretty sound to me. The general rule with implicits (that
> at least some of us here follow) is to ensure that the result types are
> used only for the purposes of the conversion. This ensures that
> conversions don't happen by accident.

What do you mean? I can see a problem if the implicitly created object
is "exposed" in the same context as the converted object (for example if
equality checks are performed). It would be really helpful to have some
recommended practices for how/when to implement implicit conversions as
it's a non-trivial task (that even the EPFL team hasn't mastered :) ).

/Jesper Nordenberg

[Jamie Webb-2]

On 2008-07-12 10:52:19 Jesper Nordenberg wrote:
> Jamie Webb wrote:
> > This seems pretty sound to me. The general rule with implicits (that
> > at least some of us here follow) is to ensure that the result types
> > are used only for the purposes of the conversion. This ensures that
> > conversions don't happen by accident.
>
> What do you mean? I can see a problem if the implicitly created
> object is "exposed" in the same context as the converted object (for
> example if equality checks are performed).

Yes, and that's a large part of the purpose of this rule. If you
consider the Pimp My Library pattern, the programmer never sees the
result value of the conversion, except as 'this' inside the new
methods. At that point, we know that the conversion has happened, and
we know the relationship between 'this' and the original object, so
everything is safe.

Likewise with Jim's usage, the conversion only happens at the point
that the method call is made. The caller therefore never sees the
conversion result, and the callee sees only the conversion result and
knows what to do with it. Again, there's no possibility for confusion.

More generally, we want to always tie the implicit conversion to some
explicit action, so that we can be clear on when it's happened. We can
accomplish that by using unique result types that are only referenced
by said actions.

> It would be really helpful
> to have some recommended practices for how/when to implement implicit
> conversions as it's a non-trivial task (that even the EPFL team
> hasn't mastered :) ).

Indeed. I'm hoping to take a stab at it at some point, but it's
probably not going to be soon...

/J

[Jim McBeath-3]

On Fri, Jul 11, 2008 at 11:51:44PM +0100, Jamie Webb wrote:

> On 2008-07-10 16:31:32 Jim McBeath wrote:
> > By writing implicit conversion methods from String to WithString
> > and from File to WithFile (or to WithNothing if the input values are
> > null), I can use a single method, so I don't need to use overloading.
> > This method effectively accepts either a String or a File as an
> > argument, but not any other type.  In addition, I can write implicit
> > conversion methods from Option[String] and Option[File], so that
> > the method effectively accepts arguments of those types as well.
> > This works for a var:Option, but not for a literal Some("x").
> >
> > Given that I have a data type which is used only for this one
> > method call, it seems like using implicit conversions to this type
> > should be a pretty safe operation.  From the perspective of the
> > programmer calling the method, it looks like a method that takes
> > an argument of type String, File, Option[String] or Option[File].
> > An argument of any other type will fail to compile.
> >
> > It seems to me that this approach could be used to create a
> > parameter which accepts an argument from any specific combination
> > of desired types, making it a way to implement polymorphism other
> > than overloading.  Are there any subtleties I am failing to see
> > here that would make this approach problematic?
>
> This seems pretty sound to me. The general rule with implicits (that
> at least some of us here follow) is to ensure that the result types are
> used only for the purposes of the conversion. This ensures that
> conversions don't happen by accident.
>
> But, do be aware of the extra allocation overhead you are causing for
> callers of your method. It's not a big deal in most cases, but I wonder
> why you are so averse to just using different names for your methods.
>
> /J

The specific implementation I use in this particular case is not
a big deal to me.  I was more interested in the question of how
this type of polymorphism from Java could be handled in Scala with
the least amount of "friction" during conversion from Java code
to Scala code.  As well, it provided a useful lesson to me about
implicit conversions and custom case classes.

--
Jim