Russ P. | 1 Mar 02:21 2012
Picon

warning for unused return value

This topic came up a while ago, but I don't recall exactly how it
ended.

Just today, I had two separate bugs due to a failure to use (i.e.,
assign) a return value from a method of an immutable class. The return
value was a modified copy of the same class type.

A simple compiler warning could have saved me substantial debugging
time. I realize that such a warning could produce false alerts, but
perhaps it could be a compiler option. Also, perhaps the warning could
be restricted to certain cases, such as a return value that is not
"Unit" or "this." Could something like that be reasonable?

I sure hope so -- it is easy to forget that a method is returning a
modified copy rather than mutating the object.

--Russ P.

Vlad Patryshev | 1 Mar 03:15 2012
Picon

Re: warning for unused return value

I'd rather make it an issue in a code revision tool, if there is such a thing for Scala.

Otherwise, it's a normal behavior, I believe, and adding a warning would mean that everybody would have to add... add what? An unnecessary val?

Thanks,
-Vlad


On Wed, Feb 29, 2012 at 5:21 PM, Russ P. <russ.paielli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
This topic came up a while ago, but I don't recall exactly how it
ended.

Just today, I had two separate bugs due to a failure to use (i.e.,
assign) a return value from a method of an immutable class. The return
value was a modified copy of the same class type.

A simple compiler warning could have saved me substantial debugging
time. I realize that such a warning could produce false alerts, but
perhaps it could be a compiler option. Also, perhaps the warning could
be restricted to certain cases, such as a return value that is not
"Unit" or "this." Could something like that be reasonable?

I sure hope so -- it is easy to forget that a method is returning a
modified copy rather than mutating the object.

--Russ P.

Russ P. | 1 Mar 04:02 2012
Picon

Re: warning for unused return value

I don't understand. Why would you need to add an unnecessary val? If
the return value is not used, then simply eliminate it and return
Unit.

If the return value is used in some cases and not in others, then
perhaps you need a design review. Why would that be? I'm probably
missing something, but I wonder if that is due to the C-style of
returning an error code (which is sometimes checked and sometimes
not).

If the warning is a compiler option, you always have an out anyway. If
it bothers you, just don't use it.

--Russ

On Feb 29, 6:15 pm, Vlad Patryshev <vpatrys...@...> wrote:
> I'd rather make it an issue in a code revision tool, if there is such a
> thing for Scala.
> Otherwise, it's a normal behavior, I believe, and adding a warning would
> mean that everybody would have to add... add what? An unnecessary val?
>
> Thanks,
> -Vlad
>
>
>
>
>
>
>
> On Wed, Feb 29, 2012 at 5:21 PM, Russ P. <russ.paie...@...> wrote:
> > This topic came up a while ago, but I don't recall exactly how it
> > ended.
>
> > Just today, I had two separate bugs due to a failure to use (i.e.,
> > assign) a return value from a method of an immutable class. The return
> > value was a modified copy of the same class type.
>
> > A simple compiler warning could have saved me substantial debugging
> > time. I realize that such a warning could produce false alerts, but
> > perhaps it could be a compiler option. Also, perhaps the warning could
> > be restricted to certain cases, such as a return value that is not
> > "Unit" or "this." Could something like that be reasonable?
>
> > I sure hope so -- it is easy to forget that a method is returning a
> > modified copy rather than mutating the object.
>
> > --Russ P.

Naftoli Gugenheim | 1 Mar 04:08 2012
Picon

Re: warning for unused return value

What if a method performs a side effect and returns a value, but you don't care about the return value (like Buffer#remove)?



On Wednesday, February 29, 2012, Russ P. wrote:
I don't understand. Why would you need to add an unnecessary val? If
the return value is not used, then simply eliminate it and return
Unit.

If the return value is used in some cases and not in others, then
perhaps you need a design review. Why would that be? I'm probably
missing something, but I wonder if that is due to the C-style of
returning an error code (which is sometimes checked and sometimes
not).

If the warning is a compiler option, you always have an out anyway. If
it bothers you, just don't use it.

--Russ


On Feb 29, 6:15 pm, Vlad Patryshev <vpatrys... <at> gmail.com> wrote:
> I'd rather make it an issue in a code revision tool, if there is such a
> thing for Scala.
> Otherwise, it's a normal behavior, I believe, and adding a warning would
> mean that everybody would have to add... add what? An unnecessary val?
>
> Thanks,
> -Vlad
>
>
>
>
>
>
>
> On Wed, Feb 29, 2012 at 5:21 PM, Russ P. <russ.paie...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > This topic came up a while ago, but I don't recall exactly how it
> > ended.
>
> > Just today, I had two separate bugs due to a failure to use (i.e.,
> > assign) a return value from a method of an immutable class. The return
> > value was a modified copy of the same class type.
>
> > A simple compiler warning could have saved me substantial debugging
> > time. I realize that such a warning could produce false alerts, but
> > perhaps it could be a compiler option. Also, perhaps the warning could
> > be restricted to certain cases, such as a return value that is not
> > "Unit" or "this." Could something like that be reasonable?
>
> > I sure hope so -- it is easy to forget that a method is returning a
> > modified copy rather than mutating the object.
>
> > --Russ P.
Vlad Patryshev | 1 Mar 04:47 2012
Picon

Re: Re: warning for unused return value



On Wed, Feb 29, 2012 at 7:02 PM, Russ P. <russ.paielli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
I don't understand. Why would you need to add an unnecessary val? If
the return value is not used, then simply eliminate it and return
Unit.

How else do you call a function that returns something? I feel like you actually have a var whose value is being replaced. Is it so? Is not it the root of the problem? Or?

And basically, if you do no
 

If the return value is used in some cases and not in others, then
perhaps you need a design review. Why would that be? I'm probably
missing something, but I wonder if that is due to the C-style of
returning an error code (which is sometimes checked and sometimes
not).

If the warning is a compiler option, you always have an out anyway. If
it bothers you, just don't use it. 

I  believe warning points to something that is wrong to do. Downcasting to Unit is not wrong. I think.
 

--Russ


On Feb 29, 6:15 pm, Vlad Patryshev <vpatrys...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I'd rather make it an issue in a code revision tool, if there is such a
> thing for Scala.
> Otherwise, it's a normal behavior, I believe, and adding a warning would
> mean that everybody would have to add... add what? An unnecessary val?
>
> Thanks,
> -Vlad
>
>
>
>
>
>
>
> On Wed, Feb 29, 2012 at 5:21 PM, Russ P. <russ.paie... <at> gmail.com> wrote:
> > This topic came up a while ago, but I don't recall exactly how it
> > ended.
>
> > Just today, I had two separate bugs due to a failure to use (i.e.,
> > assign) a return value from a method of an immutable class. The return
> > value was a modified copy of the same class type.
>
> > A simple compiler warning could have saved me substantial debugging
> > time. I realize that such a warning could produce false alerts, but
> > perhaps it could be a compiler option. Also, perhaps the warning could
> > be restricted to certain cases, such as a return value that is not
> > "Unit" or "this." Could something like that be reasonable?
>
> > I sure hope so -- it is easy to forget that a method is returning a
> > modified copy rather than mutating the object.
>
> > --Russ P.

Russ Paielli | 1 Mar 06:16 2012
Picon

Re: warning for unused return value

On Wed, Feb 29, 2012 at 7:08 PM, Naftoli Gugenheim <naftoligug-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

What if a method performs a side effect and returns a value, but you don't care about the return value (like Buffer#remove)?


I don't know. I'm just trying to suggest ways to prevent predictable bugs. Can the compiler determine whether a method returns a modified copy of an immutable class and has no side effects? If so, then there would be no reason to call the function other than to get the return value. So if the caller does not use the return value, chances are it's a bug.

As I said before, I just had two of these kinds of bugs today. I don't claim to be the worlds greatest programmer, but I'm not the worst either. It happens.

--Russ P.

--
http://RussP.us
Dennis Haupt | 1 Mar 09:50 2012
Picon
Picon

Re: warning for unused return value

i would suggest an annotation " <at> Pure" or something so the compiler knows the method has no side effect and
refuses to compile if the result is unused

-------- Original-Nachricht --------
> Datum: Wed, 29 Feb 2012 17:21:34 -0800 (PST)
> Von: "Russ P." <russ.paielli@...>
> An: scala-user <scala-user@...>
> Betreff: [scala-user] warning for unused return value

> This topic came up a while ago, but I don't recall exactly how it
> ended.
> 
> Just today, I had two separate bugs due to a failure to use (i.e.,
> assign) a return value from a method of an immutable class. The return
> value was a modified copy of the same class type.
> 
> A simple compiler warning could have saved me substantial debugging
> time. I realize that such a warning could produce false alerts, but
> perhaps it could be a compiler option. Also, perhaps the warning could
> be restricted to certain cases, such as a return value that is not
> "Unit" or "this." Could something like that be reasonable?
> 
> I sure hope so -- it is easy to forget that a method is returning a
> modified copy rather than mutating the object.
> 
> --Russ P.

√iktor Ҡlang | 1 Mar 09:55 2012
Picon

Re: warning for unused return value



On Thu, Mar 1, 2012 at 9:50 AM, Dennis Haupt <h-star-Mmb7MZpHnFY@public.gmane.org> wrote:
i would suggest an annotation " <at> Pure" or something so the compiler knows the method has no side effect and refuses to compile if the result is unused

If it's pure, then the compiler can just eliminate the call if the result is not used. So just drop the call and issue a warning.
It's worse with impure calls with return values that are not used, as they cannot be elided.
 

-------- Original-Nachricht --------
> Datum: Wed, 29 Feb 2012 17:21:34 -0800 (PST)
> Von: "Russ P." <russ.paielli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> An: scala-user <scala-user-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
> Betreff: [scala-user] warning for unused return value

> This topic came up a while ago, but I don't recall exactly how it
> ended.
>
> Just today, I had two separate bugs due to a failure to use (i.e.,
> assign) a return value from a method of an immutable class. The return
> value was a modified copy of the same class type.
>
> A simple compiler warning could have saved me substantial debugging
> time. I realize that such a warning could produce false alerts, but
> perhaps it could be a compiler option. Also, perhaps the warning could
> be restricted to certain cases, such as a return value that is not
> "Unit" or "this." Could something like that be reasonable?
>
> I sure hope so -- it is easy to forget that a method is returning a
> modified copy rather than mutating the object.
>
> --Russ P.



--
Viktor Klang

Akka Tech Lead
Typesafe - The software stack for applications that scale

Twitter: <at> viktorklang

Adam Warski | 1 Mar 10:16 2012

Re: Command pattern with parametrized return type and variance

Thanks! Very interesting to see the same problem surface on the internals lists at same moment :)

Adam

On Feb 29, 2012, at 2:45 PM, Adriaan Moors wrote:

> if Command is covariant in its type parameter you can't, in general, safely recover type information from
the knowledge in which case you are
> 
> see https://groups.google.com/d/msg/scala-internals/aHT92vcjQuc/t6EYH2IG1VQJ for an example of
how you can get a ClassCastException
> 
> On Tuesday, February 21, 2012 9:36:14 PM UTC+1, Adam Warski wrote:
> Hello,
> 
> I have a (sealed) series of commands, each of which has a different return type. The basic trait is a
Command[R], where R is the return type.
> There is then a command executor, which has a def execute[R](cmd: Command[R]): R, and executes an action
appropriate for a command using pattern matching.
> All works well until I add a variance annotation (+R) to the trait:
> 
> https://gist.github.com/1878718
> 
> Any ideas why? :)
> 
> Thanks,
> Adam

--

-- 
Adam Warski

http://twitter.com/#!/adamwarski
http://www.softwaremill.com
http://www.warski.org

Edmondo Porcu | 1 Mar 10:47 2012
Picon

Storing an entity containing an interface property

Dear All,


I have a classical entity and I want to store a property which might be of different concrete classes...something like that

trait A

class B extends A

class C extends A

<at> Entity
class MyEntity(val myProperty:A)

Is it feasible with Hibernate or Ebean or any other persistance support by Play?

Best Regards
Edmondo Porcu
      

Gmane