Re: `new Foo` vs `new Foo()`

Well, the question is why you would ever

  case class Foo {
    def foo = ???
  }

instead of

  case object Foo {
    def foo = ???
  }

If you're doing the former, maybe it is because you are actually performing
side effects.  Right?  So you should use parens?

Except

  trait Bar[A] {
    def bar: A
  }

  case class Foo[A] extends Bar[A] {
    def foo: A = ???
    def bar = foo
  }

And, um, yeah.  Case object?  Not really gonna work here.  Not sure why
this should be a case class at _all_, though--maybe just because we don't
like the default toString?

Anyway, there is at least some argument that case classes should have
parens, even if it's not terribly strong.

  --Rex


On Mon, Jul 13, 2015 at 4:05 PM, Haoyi Li <[email protected]> wrote:

> > That's the reasoning for case classes, I guess, since a
> side-effect-free case class should be a case object.
>
> This doesn't make sense to me. Since when was object allocation considered
> side effecting? When people say "avoid side effects", they usually mean you
> should allocate *more* objects, not less! Is CaseClass#copy just as
> side-effecting as mutating vars?
>
> On Mon, Jul 13, 2015 at 2:13 PM, Adriaan Moors <[email protected]>
> wrote:
>
>> If we apply the same rule as for methods, you should not add parens
>> unless your constructor is side-effecting (which is probably not a great
>> idea in itself).
>> That's the reasoning for case classes, I guess, since a side-effect-free
>> case class should be a case object.
>>
>> I tend to leave off the empty parens. Their presence should imply
>> potential side-effects.
>>
>> On Mon, Jul 13, 2015 at 1:28 PM, Jon Pretty <[email protected]> wrote:
>>
>>> I tend to include the parentheses for a couple of reasons: firstly
>>> because case classes require the parens, and by association I justify that
>>> classes should too, and secondly because instantiating a new instance of a
>>> class is side-effecting, so the "method" which does that (i.e. the
>>> constructor) should look like a side-effecting method.
>>>
>>> Additionally, for some reason, I prefer to write `new Foo().bar` rather
>>> than `(new Foo).bar`. I think the reason is that I have a slight discomfort
>>> at starting an expression with an opening parenthesis, and I've taught
>>> myself to give the `new` in `new Foo().bar` higher precedence than the `.`,
>>> even though this is counterintuitive to other parsing rules.
>>>
>>> Jon​
>>>
>>> On 13 July 2015 at 21:20, Rex Kerr <[email protected]> wrote:
>>>
>>>> That's the convention I use.  I've seen both with and without parens in
>>>> e.g. the Scala library code base.
>>>>
>>>>   --Rex
>>>>
>>>> On Mon, Jul 13, 2015 at 12:06 PM, Seth Tisue <[email protected]> wrote:
>>>>
>>>>> Is there consensus on this? Not sure whether to merge.
>>>>>
>>>>> https://github.com/scala/scala.github.com/pull/344
>>>>>
>>>>> Seth
>>>>>
>>>>>  --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "scala-language" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to [email protected].
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>  --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "scala-language" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>>>
>>> --
>>> Jon Pretty | @propensive
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "scala-language" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "scala-language" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "scala-language" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.