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
Yes, I'm just pointing out that my proposal is less ambitious.
There's a feature we already use in one context that should work equally well in another, and the two contexts are disambiguated perfectly already as far as I can tell.
Li Haoyi
@lihaoyi
yeah I understand that
I bring up coffeescript just to say
it is possible for this to go too far
not sure if this is the case here - I haven't read all the way up - but it's a real concern
Ichoran
@Ichoran
Yeah. I have the same problem with Haskell. I get that you want to have brief punctuation for things you use often, but no punctuation whatsoever is kind of hard to read. I thought we worked this out in the 17th century or whatever.
Li Haoyi
@lihaoyi
FWIW my position is mildly positive on trailing commas (like it, don't care that much), and very positive on using .foo() notation on anything without some @infix annotation (that's the style I use myself and obviously everyone else should do the same thing)
at work, Coffeescript also allows you to leave off ()s when calling arbitrary functions, and the general consensus was DON'T DO THAT, with lots of strong feelings
for similar reasons why people didn't like inferred commas: even as an experienced engineer working with the code for a year, you'd still have trouble parsing it in your head
eugene yokota
@eed3si9n
I started out being indifferent about trailing commas, but I'm surprised to learn that most modern languages secretly allow them for array and map literals - https://github.com/scala/scala.github.com/pull/533#issuecomment-239039006
David Dudson
@DavidDudson
I agree with @infix seems like one of the best ideas I've heard proposed, my colleagues are extremely happy with this too. I've seen many new Scala developers think that "Scala supports infix, so why don't we just use it!"
You then get confronted with horrible code. Although I do like infix syntax for simple one declaration "FP operators" such as map and foreach(But I wouldn’t be too fussed if it went away). eg someList foreach println
I do not like chaining them (Unless the operator is symbolic) eg. a map b map c filter d
Ichoran
@Ichoran
You don't think that in practice the difference between having to opt in with @infix and not having infix notation at all would be minimal?
Li Haoyi
@lihaoyi
I view it like use-site vs declaration-site variance
Ichoran
@Ichoran
I view it like public access modifiers.
Or like const declarations in C++.
Li Haoyi
@lihaoyi
I actually prefer needing to explicitly public things like I had to in C#
rather than having it automatic in Scala
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.