Databases
StackOverflow2013
Postsdbo
POscala 2.9: plans for type inference of function parameters with default arguments?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POscala 2.9: plans for type inference of function parameters with default arguments?
    primarykey
    data
    text
    <p>I'm just getting started with Scala. I've been using Python for research programming, and I'm converting a fairly large (~ 4000 line) Python program.</p> <p>A few comments:</p> <ol> <li>It looks like the right time to get involved in Scala, as a lot of good stuff has been added to 2.8.</li> <li>On the other hand ... I wonder why Scala doesn't seem to have a decent IO package, and why this doesn't seem to be a priority. In most languages, IO is considered one of the most fundamental operations, and parts of the language are typically designed specifically so that IO works well. For example, the IO library in Python seems one of the oldest and most stable parts of the language (at least in its interface). Yet the comments from two years ago say things like "Source.fromFile() is a massive hack, wait till so-and-so finishes the new IO package" -- and I see no movement towards finishing this. Even worse is the fact that Source.fromFile().getLines() -- which, hack or not, is the generally advertised interface -- was <strong>entirely broken</strong> by changes made in 2.9.0.1 (see <a href="https://issues.scala-lang.org/browse/SI-4662">https://issues.scala-lang.org/browse/SI-4662</a>). Evidently there is no regression testing at all for this most basic of IO interfaces, which is a bad sign.</li> <li>Type erasure sucks so incredibly badly that I really wonder why the decision was made in Scala to stick it in. Yes, I know that Java has type erasure, and Scala is built on the JVM, but the resulting need to add explicitly visible stuff like manifests, specialization annotations, etc. etc. to work around type erasure just smells really bad ... I sense ultimately that the Scala designers will realize the folly of all this, and be forced to implement proper generic typing, at which point they will then have a lot of unneeded cruft to deprecate.</li> </ol> <p>My question is:</p> <p>Are there plans to add type inference for function parameters with default arguments? It's getting a bit annoying to write stuff like this:</p> <pre><code> def add_words(words:Traversable[String], ignoreCase:Boolean=true, stopwords:Set[String]=Set[String]()) { ... } </code></pre> <p>In this case, there's simply no need at all for the type annotations on <em>ignoreCase</em> and <em>stopwords</em>, and they just add unneeded verbosity.</p> <p>Thanks for any comments from those involved in Scala development.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USUrban Vagabond
    plurals
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POscala 2.9: plans for type inference of function parameters with default arguments?
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POscala 2.9: plans for type inference of function parameters with default arguments?
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POscala 2.9: plans for type inference of function parameters with default arguments?
      1. USagilesteel
      1. VTFavorite
    1. COI don't see how the scala guys can fix type erasure because they don't own the VM.
      singulars
      1. POscala 2.9: plans for type inference of function parameters with default arguments?
      1. USStilgar
    2. CO@Stilgar they could probably pass Manifest-like information by default (which I think is what Gosu does and Kotlin will do)
      singulars
      1. POscala 2.9: plans for type inference of function parameters with default arguments?
      1. USPaolo Falabella
    3. COAlthough reified generics are slightly more convenient FOR THE DEVELOPER, than erasure, the issue is certainly not as bad as it seems. There are very good reasons for the JVM to use type erasure, which makes it more attractive environment, than for instance the .Net CLR. Check out [this link](http://olabini.com/blog/2010/07/questioning-the-reality-of-generics/) for more.
      singulars
      1. POscala 2.9: plans for type inference of function parameters with default arguments?
      1. USagilesteel
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload