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

I didn't mean to imply allocation is side-effecting. I meant the side
effect of the initializer in your case class would be invoked every time
you instantiate it, whereas the effect in an object's body occur at most
once.

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.