Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 06 2018 15:12
    @scalabot banned @fommil
  • Apr 19 2016 20:35
    @SethTisue banned @urmila007
Ichoran
@Ichoran
It adds a lot of boilerplate to a lot of code.
Li Haoyi
@lihaoyi
it takes away a lot of boilerplate to an equally large amount of code :P
Ichoran
@Ichoran
I generally view a lot of private stuff as a code smell.
I do wish private[this] was called my, though.
Li Haoyi
@lihaoyi
no idea why you don't like private
Ichoran
@Ichoran
It disguises poor APIs and prevents reuse.
David Dudson
@DavidDudson
@Ichoran I think in practice a lot of libraries will depend on infix notation (scalatest, sbt, scalaz). I think it is a necessity in a lot of cases.
Ichoran
@Ichoran
Sometimes you have to do this, but I try to make them the exception, not the rule.
Li Haoyi
@lihaoyi
the big projects whose code quality I respect contain tons of private all over the place
Ichoran
@Ichoran
Don't you think there are a LOT more than 476 or whatever it was things that aren't private in scala-js?
I'm not saying that you shouldn't have things private! Just that if that's most of what you're doing that maybe something is wrong.
David Dudson
@DavidDudson
@Ichoran i disagree, your api should only be what the user needs to care about. if you have a builder class that builds animals, you want a single public method buildAnimal() and a bunch of private methods simplifying everything down
Ichoran
@Ichoran
@DavidDudson - I think that's true if building animals is radically unlike doing anything else. Otherwise, you should factor out the common functionality into something public, and just use it instead of building so much private infrastructure.
Li Haoyi
@lihaoyi
not sure what public/private has to do with infix operators
Ichoran
@Ichoran
Heh, just that you get what you say the default is.
And if the default is that you're not infix, basically very little will be infix.
Li Haoyi
@lihaoyi
how many infix operators do you think are defined in the scala-js/scala-js codebase? :P
akka/akka probably has more
but infix vs non-infix?
I'd guess maybe a 1:100 ratio
Ichoran
@Ichoran
If you take everything that's a Function1, and drop everything that requires a closure?
David Dudson
@DavidDudson
That low, i thought it would be more. I guess it is a library. In an application codebase id say it's more then 1:1000
Ichoran
@Ichoran
Actually, I am not 100% certain what the proposal actually is, so maybe I shouldn't comment.
Is there a detailed description somewhere? I'm mostly guessing.
Ichoran
@Ichoran
Well, I just read through my Ok Either clone, and every single 1-ary method there takes a closure, which if given explicitly I would never write in infix notation, and if I had a function to pass I would prefer to see every single one in infix notation.
So I'm at 16:0 in favor of infix so far.
Maybe I better not read through my Long-packed 2D vector. Not sure there's any point there :P
If you want to count what fraction is relevant, it's about 1:1.
Ichoran
@Ichoran
If it's just what was in the Odersky keynote, it would probably increase the size of my codebase by 15%, and all of that would be boilerplate.
Jorge
@jvican
For those who haven't watched the meeting, you can see SIP-12's reaction (Uncluttering Scala's syntax ...) here: scala/scala.github.com#555.
Michael Pilquist
@mpilquist
Is there a separate HList proposal somewhere other than the records described in lampepfl/dotty#964 ? I don't see unlabelled products in that issue, only labelled products / records.
Jorge
@jvican
No, as far as I know that's the only one.
nafg
@nafg
@DavidDudson if you only have a single method then perhaps your class should just be a function (possibly containing nested methods)
But I suppose that's a straw man because your argument wasn't specific to a single method
@mpilquist I think the proposal was to make tuples basically be HListy
Michael Pilquist
@mpilquist
Thanks, I got that vibe after re-reading that ticket.
David Dudson
@DavidDudson

@nafg I guess that example was average... although a good example what I meant from the scala std library is Seq.apply()
I was more going along the lines of... If your average user types a . in one of your classes, what do they see?
I guess nesting def's inside other def's is an idiomatic scala pattern to avoid private methods, and a valid one.
But I personally like to glance at a method and see especifically it's definition, without def's.

This is a really rushed example but...

def example(xs:List[Int]): Unit = {
    def doSomething(xs:List[Int]): Unit = {

    }

    def doSomethingElse(x:Int): Unit = {

    }

    def doAThirdThing(x:Int): Unit ={

    }
    doSomething(xs)
    doSomethingElse(xs.head)
    doAThirdThing(xs.last)
  }

To me is much messier to read, even if it cleans the API up then

  def example(xs:List[Int]): Unit = {
    doSomething(xs)
    doSomethingElse(xs.head)
    doAThirdThing(xs.last)
  }

  private def doSomething(xs:List[Int]): Unit = {

  }

  private def doSomethingElse(x:Int): Unit = {

  }

  private def doAThirdThing(x:Int): Unit ={

  }

Maybe its just a holdover from java programming...

Ichoran
@Ichoran
I would private[this] all of those. I almost never use bare private, because different instances rarely should be monkeying with each other this way.
David Dudson
@DavidDudson
@Ichoran that's a fair comment
Michael Pilquist
@mpilquist
@Ichoran Curious if you use private[this] in objects too?
Ichoran
@Ichoran
No point since there's only one of them.
Michael Pilquist
@mpilquist
Right, curious if it was a habit thing based on using it in classes
Ichoran
@Ichoran
Occasionally I do to indicate that I really want the compiler to just use a bare field with no accessor methods, but it's only for performance tweaks like that.
Also, how is this related to a SIP / SLIP?
This would be related, possibly: I really wish private[this] were my. I think private[this] is one of the biggest sources of clutter in my code.
Michael Pilquist
@mpilquist
I think you are on to something there. I’m certain there’s much more private use than private[this] and I’d confidently wager there’s more private[scope] for scope != this than private[this]. And mostly due to the verbosity.
nafg
@nafg
@DavidDudson agreed
Erik LaBianca
@easel
I’d love a nicer syntax for private[scope] where scope == the current package.