2.8 text

On Tue, 2009-04-21 at 15:48 +0200, martin odersky wrote:
> Hi Toni, all:
>
> here's a draft of some text to put on the homepage to give a preview
> of 2.8. Everybody, if you have corrections or think something else
> should be mentioned, please give input to Toni.

Hi Martin,

First of all, 2.8.0 is looking great. :)

Thanks for putting this together. Although much of this has been
mentioned in messages to the mailing list, it's nice to have it all in
one place. Also, it's nice to have additional information about package
objects. I had seen the commits, but wasn't sure how it was meant to
work.

Other features that have been mentioned are tuples and function
unification, virtual traits and manifest types. Have all of these been
dropped/postponed?

Best,
Ismael

On Tue, 2009-04-21 at 15:18 +0100, Ismael Juma wrote:
> On Tue, 2009-04-21 at 15:48 +0200, martin odersky wrote:
> > Hi Toni, all:
> >
> > here's a draft of some text to put on the homepage to give a preview
> > of 2.8. Everybody, if you have corrections or think something else
> > should be mentioned, please give input to Toni.

I forgot to say, is it worth saying something about improved
interoperability with Java collections? One of the problems at the
moment is that collection.jcl does not make it easy to convert from
Scala to Java collections. Miles had started on something like this and
it would be a great addition.

Best,
Ismael

On Tue, Apr 21, 2009 at 4:18 PM, Ismael Juma wrote:
> On Tue, 2009-04-21 at 15:48 +0200, martin odersky wrote:
>> Hi Toni, all:
>>
>> here's a draft of some text to put on the homepage to give a preview
>> of 2.8. Everybody, if you have corrections or think something else
>> should be mentioned, please give input to Toni.
>
> Hi Martin,
>
> First of all, 2.8.0 is looking great. :)
>
> Thanks for putting this together. Although much of this has been
> mentioned in messages to the mailing list, it's nice to have it all in
> one place. Also, it's nice to have additional information about package
> objects. I had seen the commits, but wasn't sure how it was meant to
> work.
>
> Other features that have been mentioned are tuples and function
> unification, virtual traits and manifest types. Have all of these been
> dropped/postponed?
>
None of them are ready for 2.8 yet. I forgot to mention timeframe: We
want to have the first beta out beginning of June. So that's just 6
more weeks.

Cheers

On Tue, 2009-04-21 at 16:40 +0200, martin odersky wrote:
> None of them are ready for 2.8 yet. I forgot to mention timeframe: We
> want to have the first beta out beginning of June. So that's just 6
> more weeks.

Makes sense. I had expected 2.8.0 to take longer, so that timeframe is
great news. :)

Best,
Ismael

On Tue, Apr 21, 2009 at 03:48:45PM +0200, martin odersky wrote:
> The 2.8 version will also drop most operations that were deprecated in
> earlier versions. The class file format and compilation internals will
> be changed to some degree, so that programs compiled under 2.8 will
> not be compatible with binaries compiled earlier. Source compatibility
> should be by and large assured, however.

Should this section maybe mention that 1.4 compatibility is being
dropped? Also it would be good to have a list of known behavioral
changes somewhere (not in this announcement) such as val initialization
order and whatever I can't think of.

Still time to deprecate case class inheritance in 2.8!

- Named and by default parameters.
Method arguments can be passed by names, and method parameters can
have default values.

I think we should call them "named and default arguments". Parameters
have always been named, it's really the arguments which can now be
named. Also for defaults, "arguments" makes more sense; the defaults
are default values for missing arguments, not for missing parameters.

Lukas

martin odersky wrote:
> Hi Toni, all:
>

> - Package objects.
> Packages can now be defined not just by files in some directory, but
> in addition by special object that lists additional members of the
> package. For instance, you could add a number of type aliases, which
> would then be visible as members of the package. This functionality is
> used in the new collection libraries to ensure backwards
> compatibility. For instance class List in the new library will live in
> package scala.collection.immutable. But code that accesses it as a
> scala.List will still work, because there is a package object
> definition like this:
>
> package object scala
> type List[+A] = scala.collection.immutable.List[A]
> val List = scala.collection.immutable.List
> ...
> }

Can one get depreciation warnings for using the old name? Could the type alias
be annotated:

package object scala
@deprecated
type List[+A] = scala.collection.immutable.List[A]

@deprecated
val List = scala.collection.immutable.List
...
}

Or are we expecting scala.List to still be used?

Blair

On Tue, Apr 21, 2009 at 7:25 PM, Blair Zajac wrote:
> martin odersky wrote:
>>
>> Hi Toni, all:
>>
>
>> - Package objects.
>> Packages can now be defined not just by files in some directory, but
>> in addition by special object that lists additional members of the
>> package. For instance, you could add a number of type aliases, which
>> would then be visible as members of the package. This functionality is
>> used in the new collection libraries to ensure backwards
>> compatibility. For instance class List in the new library will live in
>> package scala.collection.immutable. But code that accesses it as a
>> scala.List will still work, because there is a package object
>> definition like this:
>>
>>    package object scala
>>        type List[+A] = scala.collection.immutable.List[A]
>>        val List = scala.collection.immutable.List
>>        ...
>>   }
>
> Can one get depreciation warnings for using the old name?  Could the type
> alias be annotated:
>
>     package object scala
>         @deprecated
>         type List[+A] = scala.collection.immutable.List[A]
>
>         @deprecated
>         val List = scala.collection.immutable.List
>         ...
>    }
>
> Or are we expecting scala.List to still be used?
>
> Blair
>
Blair,

We can attach deprecation warnings to such aliases.
We have not yet decided yet whether we should do that at the outset,
or wait until we gain more experience with the new library layout.

Cheers

There were suggestions a while back (see: http://www.nabble.com/Summary(2)---things-to-drop-td20665104.html) that the rules for empty parameter lists might change: they would be optional only when calling Java methods.

Is this change still being considered for 2.8?

--j

On Tue, Apr 21, 2009 at 10:34 AM, martin odersky <martin.odersky@epfl.ch> wrote:

On Tue, Apr 21, 2009 at 7:25 PM, Blair Zajac <blair@orcaware.com> wrote:
> martin odersky wrote:
>>
>> Hi Toni, all:
>>
>
>> - Package objects.
>> Packages can now be defined not just by files in some directory, but
>> in addition by special object that lists additional members of the
>> package. For instance, you could add a number of type aliases, which
>> would then be visible as members of the package. This functionality is
>> used in the new collection libraries to ensure backwards
>> compatibility. For instance class List in the new library will live in
>> package scala.collection.immutable. But code that accesses it as a
>> scala.List will still work, because there is a package object
>> definition like this:
>>
>>    package object scala
>>        type List[+A] = scala.collection.immutable.List[A]
>>        val List = scala.collection.immutable.List
>>        ...
>>   }
>
> Can one get depreciation warnings for using the old name?  Could the type
> alias be annotated:
>
>     package object scala
>         @deprecated
>         type List[+A] = scala.collection.immutable.List[A]
>
>         @deprecated
>         val List = scala.collection.immutable.List
>         ...
>    }
>
> Or are we expecting scala.List to still be used?
>
> Blair
>
Blair,

We can attach deprecation warnings to such aliases.
We have not yet decided yet whether we should do that at the outset,
or wait until we gain more experience with the new library layout.

Cheers

On Thu, Apr 23, 2009 at 1:46 AM, Jorge Ortiz wrote:
> There were suggestions a while back (see:
> http://www.nabble.com/Summary(2)---things-to-drop-td20665104.html) that the
> rules for empty parameter lists might change: they would be optional only
> when calling Java methods.
>
> Is this change still being considered for 2.8?
>
Yes, I think that would be a good point to introduce this rule.
Probably deprecate at first, and then implement fully for 2.9.

Cheers