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
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.
Jorge
@jvican
Eugene explains why the Committee is rejecting SIP-16: Self-cleaning macros scala/scala.github.com#57.
Matthew de Detrich
@mdedetrich
@lihaoyi @Ichoran I agree regarding the coffeescript, I used it in my previous company and there ends up being way too much magic in how the expressions end up being parsed
I think that if inferred commas are just limited to inside parans that are multiline it should prevent the same problem that coffeescript has, especially considering that Scala (unlike other languages) we share the same syntax with arrays
Also I am a big fan of the @infix notation with one proviso. Obviously certain operators almost always make sense infix (i.e. the dot method for dot product in maths mentioned earlier), however it can also make sense if you just have a single application. Where it starts getting silly is when you have a trailing sentance of words which are chained infix calls, it becomes really hard to track ordering
So I am generally a fan of @infix because I really do think that it only applies to certain types of operators (mainly math based ones), and that if you use it in other situations, you are probably doing it the wrong way
Matthew de Detrich
@mdedetrich
@mpilquist Agreed, but I think private is the way it is because its mimicking the keyword from Java