These are chat archives for broadinstitute/hail

2nd
Aug 2016
Laurent Francioli
@lfrancioli
Aug 02 2016 18:13
I can’t see hail-dev anymore… is this the only hail channel now?
Tim Poterba
@tpoterba
Aug 02 2016 18:13
I archived hail-dev
Jon Bloom
@jbloom22
Aug 02 2016 18:13
Tim just archived it
Tim Poterba
@tpoterba
Aug 02 2016 18:13
this is the only dev channel now
Laurent Francioli
@lfrancioli
Aug 02 2016 18:13
I’m talking about the gitter one
Jon Bloom
@jbloom22
Aug 02 2016 18:13
Tim where can we see the archive?
Laurent Francioli
@lfrancioli
Aug 02 2016 18:13
OK
Jon Bloom
@jbloom22
Aug 02 2016 18:13
i still see it
in the same place
Tim Poterba
@tpoterba
Aug 02 2016 18:14
oh, hail-dev on gitter
Jon Bloom
@jbloom22
Aug 02 2016 18:14
new symbol though, indicating archiving
Laurent Francioli
@lfrancioli
Aug 02 2016 18:14
Seemed like there was an empty hail-dev gitter channel is why I asked
Tim Poterba
@tpoterba
Aug 02 2016 18:14
there was
I don’t know where it went
Laurent Francioli
@lfrancioli
Aug 02 2016 18:14
haha, ok
Tim Poterba
@tpoterba
Aug 02 2016 18:15
actually, this is the hail-dev channel
for now
(Cotton deleted the other gitter one)
Laurent Francioli
@lfrancioli
Aug 02 2016 18:16
cool!
Mitja Kurki
@Fedja
Aug 02 2016 19:37
whats the logic in Pedigree.scala for having Pedigree as a case class?
Tim Poterba
@tpoterba
Aug 02 2016 19:38
as opposed to a class?
Mitja Kurki
@Fedja
Aug 02 2016 19:38
yes
Tim Poterba
@tpoterba
Aug 02 2016 19:39
case classes have nice properties like good toString, built in extractors for pattern matching, and provide access to their class values
if it didn’t have case, we’d need a def trios = this.trios
generally if it can be a case class, it should be
Mitja Kurki
@Fedja
Aug 02 2016 19:39
Why would you not then always use case classes?
ok
Laurent Francioli
@lfrancioli
Aug 02 2016 19:57
classes also expose their class values
in the same way
Tim Poterba
@tpoterba
Aug 02 2016 19:57
ah you’re right

reason to use case classes from stack overflow:

Case classes can be seen as plain and immutable data-holding objects that should exclusively depend on their constructor arguments.

This functional concept allows us to

use a compact initialisation syntax (Node(1, Leaf(2), None)))
decompose them using pattern matching
have equality comparisons implicitly defined

Mitja Kurki
@Fedja
Aug 02 2016 20:21
so there is no other reason in the pedigree case other than matchability?
Does it enforce internal immutability?
Jon Bloom
@jbloom22
Aug 02 2016 22:07

No, case classes do not enforce immutability, but don't expect good behavior from the providd equality and hashing if the fields are mutable. With both classes and case classes take vals by default , you prepend var. For more, see here:

http://stackoverflow.com/questions/2312881/what-is-the-difference-between-scalas-case-class-and-class

Mitja Kurki
@Fedja
Aug 02 2016 22:12
Thanks I think I got it. Usage of case class in pedigree is effectively just to get the automatic get/set, equality and matching are quite meaningless there. Syntactic high fructose corn syrup, which is quite powerful and nice…. just maybe not in this case! Just thought to ask if there was some deeper reason for that.
Jon Bloom
@jbloom22
Aug 02 2016 22:13
Yeah, it really isn't needed for Pedigree since it's just wrapping an Array (mutable)
in fact, I probably should change it to class and implement equality using sameElements
Jon Bloom
@jbloom22
Aug 02 2016 22:21
I'm going to change it to: class Pedigree(val trios: Array[Trio])
Only other change to chose is adding new in new Pedigree(trios) in the apply. All tests still pass.
Tim Poterba
@tpoterba
Aug 02 2016 22:28
Why not IndexedSeq[Trio]?
Mitja Kurki
@Fedja
Aug 02 2016 22:31
I don’t feel strongly about it. I just always tend to do the minimal thing and start wondering why something was done if seemingly extra has been added. But thats just me being newbie to Scala. It does not bloat the class that much as far as I understand. If you are changing...I can’t think of a reason for testing equality or hashing?
why IndexSeq instead of Array?
Tim Poterba
@tpoterba
Aug 02 2016 22:32
it’s functional. Arrays are mutable and special
Mitja Kurki
@Fedja
Aug 02 2016 22:32
ah… I though that there are both versions
Tim Poterba
@tpoterba
Aug 02 2016 22:33
scala> Array(1) == Array(1)
res0: Boolean = false

scala> IndexedSeq(1) == IndexedSeq(1)
res1: Boolean = true
Mitja Kurki
@Fedja
Aug 02 2016 22:33
mutable and non-mutable
Tim Poterba
@tpoterba
Aug 02 2016 22:34
we haven’t really had a use for any mutable data structures besides builders, buffers, maps, and sets
if you need a mutable indexed seq, might as well use array
Mitja Kurki
@Fedja
Aug 02 2016 22:34
I meant that I thought arrays had both
Tim Poterba
@tpoterba
Aug 02 2016 22:34
ahh
indexed seq is the immutable array
Mitja Kurki
@Fedja
Aug 02 2016 22:35
makes sense but could be more obvious having mutable and non-mutable array or indexed seq but not both
Tim Poterba
@tpoterba
Aug 02 2016 22:36
I think Arrays aren’t really very scala-y
Mitja Kurki
@Fedja
Aug 02 2016 22:36
if there are no other differences
Seems not…. I’m wondering why it exists at all
Tim Poterba
@tpoterba
Aug 02 2016 22:36
there are
arrays don’t box
which is a HUGE deal
Mitja Kurki
@Fedja
Aug 02 2016 22:37
ah
again… why does it exist :)
Tim Poterba
@tpoterba
Aug 02 2016 22:37
arrays? or indexed seqs?
Mitja Kurki
@Fedja
Aug 02 2016 22:38
array…. its faster without autoboxing though
Tim Poterba
@tpoterba
Aug 02 2016 22:38
yeah arrays are way faster
Mitja Kurki
@Fedja
Aug 02 2016 22:39
Whats the difference with ArrayBuffer and mutable Array?
ah
got it already
all clear and necessary… sorry for thinking 'out loud’… or visibly I should say
Tim Poterba
@tpoterba
Aug 02 2016 22:40
no problem!
Mitja Kurki
@Fedja
Aug 02 2016 22:41
IndexedSeq[Trio] gets my vote also :)
Jon Bloom
@jbloom22
Aug 02 2016 22:52
mine too. I'll change it