Scala Debate

I would like to propose a SIP to simplify and clean up Scaladoc. Thesimplest way to explain it is to start with an example of a short Scalasource file that illustrates it:

>> This is because the type system does not allow to restrict [a] to only
>> contain actual lists....
>
> Yes it does. Try it.

Do you mean by using strict fields?

Hi,

I'm pretty sure that is has come up already, but is there interest in having some kind of @Beta annotation to signify that some method/class is subject to change?

Google seems to have something comparable in Guava: com.google.common.annotations.Beta ("Signifies that a public API (public class, method or field) is subject to incompatible changes, or even removal, in a future release.").

Would it make sense to have something standardized in the standard library under scala.annotation?

Thanks and bye,

Simon

A thought, tangenting off of Eric's excellent post-mortem:
On Thu, Dec 8, 2011 at 9:47 AM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:

1. Most of my team is scared of Scala, probably because of the various Scala presentations I have given over the years. Face it - FP just scares some people.

Just a suggestion for folks to keep in mind: a bit of spoon-feeding and leading by example can help.

I've just spent the last few weeks building some utility code in Scala and thought I would share my experience.

I've been playing with Scala for about 4 years now and consider myself an informed, but casual user of Scala. I have an MSc in Computing Science and I am currently a Software Architect at Kodak.

After much consideration I recently decided to incorporate some Scala in production code:

Cay, there's a lot of disagreement but thanks for your endurance. I'm
confident that any changes made will be an improvement!

On Tue, Dec 6, 2011 at 11:26 AM, Cay Horstmann wrote:
> On Tue, Dec 6, 2011 at 6:03 AM, Daniel Sobral wrote:
>> On Mon, Dec 5, 2011 at 19:05, Cay Horstmann wrote:
>>>> Also, if you provide +: as an extractor for all collections, you add
>>>> another inconsistency. Will you also provide :+? What about efficiency
>>>> concerns?
>>>
>>> No, I had thought of providing an +: extractor only for lists. It
>>> doesn't make sense to destructure an arbitrary sequence.
>>
>> That's non-sense!

On Mon, Dec 5, 2011 at 6:10 PM, Marius Danciu <marius [dot] danciu [at] gmail [dot] com> wrote:

You can use package objects for this.
package object Foo {  type X = Int}

More info:
http://www.scala-lang.org/docu/files/packageobjects/packageobjects.html 

Why is OK to do this:

object Foo { type X = Int }

but not at top (package) level:

type X = Int // error

Related: does a package implicitly define a top-level object?

Also, please let me know if there is a more suitable list for such questions.

Thanks!