- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Scala IO Action items.
Wed, 2009-09-09, 09:06
I have spent several hours over the last few days studying jsr203 and the scala.io API and have come up with following thoughts.
* JSR203 is designed to be extensible and performant
* JSR203 design acknowledges several difficult problems creating a cross-platform file API
* It tries to still be easy to use
* I think it is important to make note of these design decisions and make an API that can be implemented efficiently based on JSR203 (in the future)
* We cannot depend on Java 7 yet so we need to choose an implementable subset of JSR203 that can be implemented on Java 5 and 6. (do we support 5?)
* The current API is a good starting point since it is obviously strongly influenced by JSR203
I propose the following action items:
1. Choose a subset of the full JSR spec that is implementable on the currently supported JVMs. Certain methods, like isSymlink would be flagged as only being capable of making an educated guess to whether the file represents a symlink.
In the future when we can add a Java 7 dependency or when a back-port is available we can add the items that are in jsr 203 and we can update our implementation to be based on that work.
2.
2.a The current API is already based to a certain degree on JSR203. I would like to see that relationship documented. Methods that have an analog in JSR203 should have that relationship mentioned and have the differences noted.
2.b We need to analyze the current API for decisions that go against the JSR203 and determine if we would like to make this change. The example that comes to mind is the decision to have File/Directory as subclasses of Path and be only sort of related to JSR203 FileReference and Directory.
2.c Since it is agreed that the jsr203 API is not the nicest, nor is it very scala-like, we can next visit the API with the intent to make it integrate nicely with Scala. I would like comments that indicate a mapping to the jsr203 API for those methods that originated from the selection in step 1.
3. Analyze API for opportunities to add Scala idioms.
4. Add implementations.
I am not one to try to get other to do my work for me so I will start with topic 1 and hopefully have that available for review in the next couple days. For now I am going to reduce scope to the File/Path/Directory API and leave IO out of the equation. I am going to assume interoperability with the current nio and stream implementations.
Comments?
Jesse
* JSR203 is designed to be extensible and performant
* JSR203 design acknowledges several difficult problems creating a cross-platform file API
* It tries to still be easy to use
* I think it is important to make note of these design decisions and make an API that can be implemented efficiently based on JSR203 (in the future)
* We cannot depend on Java 7 yet so we need to choose an implementable subset of JSR203 that can be implemented on Java 5 and 6. (do we support 5?)
* The current API is a good starting point since it is obviously strongly influenced by JSR203
I propose the following action items:
1. Choose a subset of the full JSR spec that is implementable on the currently supported JVMs. Certain methods, like isSymlink would be flagged as only being capable of making an educated guess to whether the file represents a symlink.
In the future when we can add a Java 7 dependency or when a back-port is available we can add the items that are in jsr 203 and we can update our implementation to be based on that work.
2.
2.a The current API is already based to a certain degree on JSR203. I would like to see that relationship documented. Methods that have an analog in JSR203 should have that relationship mentioned and have the differences noted.
2.b We need to analyze the current API for decisions that go against the JSR203 and determine if we would like to make this change. The example that comes to mind is the decision to have File/Directory as subclasses of Path and be only sort of related to JSR203 FileReference and Directory.
2.c Since it is agreed that the jsr203 API is not the nicest, nor is it very scala-like, we can next visit the API with the intent to make it integrate nicely with Scala. I would like comments that indicate a mapping to the jsr203 API for those methods that originated from the selection in step 1.
3. Analyze API for opportunities to add Scala idioms.
4. Add implementations.
I am not one to try to get other to do my work for me so I will start with topic 1 and hopefully have that available for review in the next couple days. For now I am going to reduce scope to the File/Path/Directory API and leave IO out of the equation. I am going to assume interoperability with the current nio and stream implementations.
Comments?
Jesse
Wed, 2009-09-09, 14:47
#2
Re: Scala IO Action items.
I hate to say this, but I think we need to take a step back and make sure we agree on our objectives. I think it's critical that:
(1) will be shipped with 2.8(2) provides a reasonably complete feature set (3) is robust and has a decent test quite(4) modify other parts of the Scala codebase that do IO to use the new functions(5) we've used in writing a few programs so that we have some understanding of what the API is really like to use
-Erik
On Wed, Sep 9, 2009 at 4:06 AM, Jesse Eichar <jeichar.w@gmail.com> wrote:
--
http://erikengbrecht.blogspot.com/
(1) will be shipped with 2.8(2) provides a reasonably complete feature set (3) is robust and has a decent test quite(4) modify other parts of the Scala codebase that do IO to use the new functions(5) we've used in writing a few programs so that we have some understanding of what the API is really like to use
-Erik
On Wed, Sep 9, 2009 at 4:06 AM, Jesse Eichar <jeichar.w@gmail.com> wrote:
I have spent several hours over the last few days studying jsr203 and the scala.io API and have come up with following thoughts.
* JSR203 is designed to be extensible and performant
* JSR203 design acknowledges several difficult problems creating a cross-platform file API
* It tries to still be easy to use
* I think it is important to make note of these design decisions and make an API that can be implemented efficiently based on JSR203 (in the future)
* We cannot depend on Java 7 yet so we need to choose an implementable subset of JSR203 that can be implemented on Java 5 and 6. (do we support 5?)
* The current API is a good starting point since it is obviously strongly influenced by JSR203
I propose the following action items:
1. Choose a subset of the full JSR spec that is implementable on the currently supported JVMs. Certain methods, like isSymlink would be flagged as only being capable of making an educated guess to whether the file represents a symlink.
In the future when we can add a Java 7 dependency or when a back-port is available we can add the items that are in jsr 203 and we can update our implementation to be based on that work.
2.
2.a The current API is already based to a certain degree on JSR203. I would like to see that relationship documented. Methods that have an analog in JSR203 should have that relationship mentioned and have the differences noted.
2.b We need to analyze the current API for decisions that go against the JSR203 and determine if we would like to make this change. The example that comes to mind is the decision to have File/Directory as subclasses of Path and be only sort of related to JSR203 FileReference and Directory.
2.c Since it is agreed that the jsr203 API is not the nicest, nor is it very scala-like, we can next visit the API with the intent to make it integrate nicely with Scala. I would like comments that indicate a mapping to the jsr203 API for those methods that originated from the selection in step 1.
3. Analyze API for opportunities to add Scala idioms.
4. Add implementations.
I am not one to try to get other to do my work for me so I will start with topic 1 and hopefully have that available for review in the next couple days. For now I am going to reduce scope to the File/Path/Directory API and leave IO out of the equation. I am going to assume interoperability with the current nio and stream implementations.
Comments?
Jesse
--
http://erikengbrecht.blogspot.com/
Wed, 2009-09-09, 14:57
#3
Re: Scala IO Action items.
On Wed, Sep 9, 2009 at 2:38 PM, Erik Engbrecht wrote:
> I hate to say this, but I think we need to take a step back and make sure we
> agree on our objectives. I think it's critical that:
> (1) will be shipped with 2.8
Do you really see this as critical? Is the lack of standard
Scala-specific I/O APIs really holding back adoption of Scala on that
short a timescale?
I would tend to say not, at least not relative to the collections, or
arrays, or IDE support.
Cheers,
Miles
Wed, 2009-09-09, 15:37
#4
Re: Scala IO Action items.
+5
Definitely the right way to go. Of course, the devil will be in the details...
On Wednesday, September 9, 2009, Miles Sabin wrote:
> On Wed, Sep 9, 2009 at 9:06 AM, Jesse Eichar wrote:
>> Comments?
>
> Excellent stuff ...
>
> Cheers,
>
>
> Miles
>
> --
> Miles Sabin
> tel: +44 (0)7813 944 528
> skype: milessabin
> http://www.chuusai.com/
> http://twitter.com/milessabin
>
Wed, 2009-09-09, 15:47
#5
Re: Scala IO Action items.
I agree that we need to make sure we agree on our objectives.
One of the things I do not want to do is redo the design work and development that has been done. I have used the current API a fair bit in a project that I have been working on and I have been following the progress of trunk (although not your repository unfortunately). I have the feeling that it is fairly close to the JSR and if we can make the relationships between the JSR and the API we will be able to more easily identify the places where we are designing ourselves into a corner.
I think that I can do most of my action items and result in a plan that will result in fairly benign refactorings so we can keep the tests and implementations in place. Also there is no reason that we need to implement the full API. But we do need to be able to leave it open for future extensions and changes.
One benefit of the plan is we can point to how our API relates to JSR203 we have more built-in documentation and people who would like to see something close to JSR-203 will be able to understand more clearly the decisions that have been made.
I would like to see the API in 2.8 as well, but we cannot have something 1/2 baked in the core library because Scala we have that API nearly for ever. Scala is getting enough reputation that it is going to be more difficult to make large changes.
Am I making sense?
Jesse
On Wed, Sep 9, 2009 at 3:38 PM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:
One of the things I do not want to do is redo the design work and development that has been done. I have used the current API a fair bit in a project that I have been working on and I have been following the progress of trunk (although not your repository unfortunately). I have the feeling that it is fairly close to the JSR and if we can make the relationships between the JSR and the API we will be able to more easily identify the places where we are designing ourselves into a corner.
I think that I can do most of my action items and result in a plan that will result in fairly benign refactorings so we can keep the tests and implementations in place. Also there is no reason that we need to implement the full API. But we do need to be able to leave it open for future extensions and changes.
One benefit of the plan is we can point to how our API relates to JSR203 we have more built-in documentation and people who would like to see something close to JSR-203 will be able to understand more clearly the decisions that have been made.
I would like to see the API in 2.8 as well, but we cannot have something 1/2 baked in the core library because Scala we have that API nearly for ever. Scala is getting enough reputation that it is going to be more difficult to make large changes.
Am I making sense?
Jesse
On Wed, Sep 9, 2009 at 3:38 PM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:
I hate to say this, but I think we need to take a step back and make sure we agree on our objectives. I think it's critical that:
(1) will be shipped with 2.8(2) provides a reasonably complete feature set (3) is robust and has a decent test quite(4) modify other parts of the Scala codebase that do IO to use the new functions(5) we've used in writing a few programs so that we have some understanding of what the API is really like to use
-Erik
On Wed, Sep 9, 2009 at 4:06 AM, Jesse Eichar <jeichar.w@gmail.com> wrote:
I have spent several hours over the last few days studying jsr203 and the scala.io API and have come up with following thoughts.
* JSR203 is designed to be extensible and performant
* JSR203 design acknowledges several difficult problems creating a cross-platform file API
* It tries to still be easy to use
* I think it is important to make note of these design decisions and make an API that can be implemented efficiently based on JSR203 (in the future)
* We cannot depend on Java 7 yet so we need to choose an implementable subset of JSR203 that can be implemented on Java 5 and 6. (do we support 5?)
* The current API is a good starting point since it is obviously strongly influenced by JSR203
I propose the following action items:
1. Choose a subset of the full JSR spec that is implementable on the currently supported JVMs. Certain methods, like isSymlink would be flagged as only being capable of making an educated guess to whether the file represents a symlink.
In the future when we can add a Java 7 dependency or when a back-port is available we can add the items that are in jsr 203 and we can update our implementation to be based on that work.
2.
2.a The current API is already based to a certain degree on JSR203. I would like to see that relationship documented. Methods that have an analog in JSR203 should have that relationship mentioned and have the differences noted.
2.b We need to analyze the current API for decisions that go against the JSR203 and determine if we would like to make this change. The example that comes to mind is the decision to have File/Directory as subclasses of Path and be only sort of related to JSR203 FileReference and Directory.
2.c Since it is agreed that the jsr203 API is not the nicest, nor is it very scala-like, we can next visit the API with the intent to make it integrate nicely with Scala. I would like comments that indicate a mapping to the jsr203 API for those methods that originated from the selection in step 1.
3. Analyze API for opportunities to add Scala idioms.
4. Add implementations.
I am not one to try to get other to do my work for me so I will start with topic 1 and hopefully have that available for review in the next couple days. For now I am going to reduce scope to the File/Path/Directory API and leave IO out of the equation. I am going to assume interoperability with the current nio and stream implementations.
Comments?
Jesse
--
http://erikengbrecht.blogspot.com/
Wed, 2009-09-09, 15:47
#6
Re: Scala IO Action items.
I have seen enough complains about I/O that I think yes, it is critical.
Personally, I always think of languages without a decent I/O library as a "toy language". I get a vague feeling of an academic language where one can write beautiful algorithms, but can't process a single file. At least we have something, but that something is considered by just about everyone, including the original author, it seems, to be broken.
So, I'll put it another way. Which feature would most likely positively influence professional programmers: a further enhancement to the type system, or a decent I/O library?
On Wed, Sep 9, 2009 at 10:43 AM, Miles Sabin <miles@milessabin.com> wrote:
--
Daniel C. Sobral
Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.
On Wed, Sep 9, 2009 at 10:43 AM, Miles Sabin <miles@milessabin.com> wrote:
On Wed, Sep 9, 2009 at 2:38 PM, Erik Engbrecht<erik.engbrecht@gmail.com> wrote:
> I hate to say this, but I think we need to take a step back and make sure we
> agree on our objectives. I think it's critical that:
> (1) will be shipped with 2.8
Do you really see this as critical? Is the lack of standard
Scala-specific I/O APIs really holding back adoption of Scala on that
short a timescale?
I would tend to say not, at least not relative to the collections, or
arrays, or IDE support.
Cheers,
Miles
--
Miles Sabin
tel: +44 (0)7813 944 528
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin
--
Daniel C. Sobral
Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.
Wed, 2009-09-09, 15:57
#7
Re: Scala IO Action items.
On Sep 9, 2009, at 16:38, Erik Engbrecht wrote:
I hate to say this, but I think we need to take a step back and make sure we agree on our objectives. I think it's critical that:
(1) will be shipped with 2.8(2) provides a reasonably complete feature set (3) is robust and has a decent test quite(4) modify other parts of the Scala codebase that do IO to use the new functions(5) we've used in writing a few programs so that we have some understanding of what the API is really like to use
I think everything from (2) - (5), which are excellent points by the way, contradicts (1). If we make shipment with 2.8 a goal, there is a chance we will lose big, considering the 2.8 proposed timeframe (not in the far future).
I propose to leave IO in scala as is for now and not rush anything. We cannot afford to reconsider things, say in 2.9 or 3.0. At least not much and there are so many dimensions to consider.
BRChristos
--
__~O
-\ <, Christos KK Loverdos
(*)/ (*) http://ckkloverdos.com
Wed, 2009-09-09, 15:57
#8
Re: Scala IO Action items.
On Sep 9, 2009, at 17:40, Daniel Sobral wrote:
I have seen enough complains about I/O that I think yes, it is critical. Personally, I always think of languages without a decent I/O library as a "toy language". I get a vague feeling of an academic language where one can write beautiful algorithms, but can't process a single file. At least we have something, but that something is considered by just about everyone, including the original author, it seems, to be broken. So, I'll put it another way. Which feature would most likely positively influence professional programmers: a further enhancement to the type system, or a decent I/O library?
A descent I/O library, there is ABSOLUTELY NO QUESTION ABOUT IT.
But it has to be done carefully.
On Wed, Sep 9, 2009 at 10:43 AM, Miles Sabin <miles@milessabin.com> wrote:
On Wed, Sep 9, 2009 at 2:38 PM, Erik Engbrecht<erik.engbrecht@gmail.com> wrote:
> I hate to say this, but I think we need to take a step back and make sure we
> agree on our objectives. I think it's critical that:
> (1) will be shipped with 2.8
Do you really see this as critical? Is the lack of standard
Scala-specific I/O APIs really holding back adoption of Scala on that
short a timescale?
I would tend to say not, at least not relative to the collections, or
arrays, or IDE support.
Cheers,
Miles
--
Miles Sabin
tel: +44 (0)7813 944 528
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin
--
Daniel C. Sobral
Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.
--
__~O
-\ <, Christos KK Loverdos
(*)/ (*) http://ckkloverdos.com
Wed, 2009-09-09, 15:57
#9
Re: Scala IO Action items.
On Wed, Sep 9, 2009 at 3:40 PM, Daniel Sobral wrote:
> Personally, I always think of languages without a decent I/O library as a
> "toy language". I get a vague feeling of an academic language where one can
> write beautiful algorithms, but can't process a single file. At least we
> have something, but that something is considered by just about everyone,
> including the original author, it seems, to be broken.
Scala is in a very different position from most "academic" languages
because it has seamless access to Java's I/O libraries ... they might
not be pretty, but they get the job done.
On the one hand that means that the urgency for creating
Scala-specific I/O libraries is lessened. But on the other, it means
that we have to offer something which is both on a par with respect to
functionality and clearly superior with respect to usability. I'd love
to be proved wrong, but think a 2.8 timeframe is unrealistic for that.
Cheers,
Miles
Wed, 2009-09-09, 16:07
#10
Re: Scala IO Action items.
What's the timeline for 2.8? It obviously has a significant affect on whether we should plan to ship with it or not...
On Wed, Sep 9, 2009 at 10:40 AM, Christos KK Loverdos <loverdos@gmail.com> wrote:
--
http://erikengbrecht.blogspot.com/
On Wed, Sep 9, 2009 at 10:40 AM, Christos KK Loverdos <loverdos@gmail.com> wrote:
On Sep 9, 2009, at 16:38, Erik Engbrecht wrote:I hate to say this, but I think we need to take a step back and make sure we agree on our objectives. I think it's critical that:
(1) will be shipped with 2.8 (2) provides a reasonably complete feature set (3) is robust and has a decent test quite(4) modify other parts of the Scala codebase that do IO to use the new functions(5) we've used in writing a few programs so that we have some understanding of what the API is really like to use
I think everything from (2) - (5), which are excellent points by the way, contradicts (1). If we make shipment with 2.8 a goal, there is a chance we will lose big, considering the 2.8 proposed timeframe (not in the far future).
I propose to leave IO in scala as is for now and not rush anything. We cannot afford to reconsider things, say in 2.9 or 3.0. At least not much and there are so many dimensions to consider.
BRChristos
--
__~O
-\ <, Christos KK Loverdos
(*)/ (*) http://ckkloverdos.com
--
http://erikengbrecht.blogspot.com/
Wed, 2009-09-09, 16:07
#11
Re: Scala IO Action items.
> I'd love to be proved wrong, but think a 2.8 timeframe is
> unrealistic for that.
>
> Cheers,
>
>
> Miles
So Miles and I are pretty direct about that.
Guys, Scala 2.8 already incorporates both language and library
changes. That should be a good indication to resist introducing more
features. FWIW, I think it would make bad politics [1].
BR
Christos
[1] Always having in mind that 2.8 is intended to ship soon.
Wed, 2009-09-09, 16:17
#12
Re: Scala IO Action items.
If I am not mistaken, Martin said BETA in very few weeks (3-4?). It is in some recent thread in the lists.
On Sep 9, 2009, at 17:44, Erik Engbrecht wrote:
--
__~O
-\ <, Christos KK Loverdos
(*)/ (*) http://ckkloverdos.com
On Sep 9, 2009, at 17:44, Erik Engbrecht wrote:
What's the timeline for 2.8? It obviously has a significant affect on whether we should plan to ship with it or not...
On Wed, Sep 9, 2009 at 10:40 AM, Christos KK Loverdos <loverdos@gmail.com> wrote:
On Sep 9, 2009, at 16:38, Erik Engbrecht wrote:I hate to say this, but I think we need to take a step back and make sure we agree on our objectives. I think it's critical that:
(1) will be shipped with 2.8 (2) provides a reasonably complete feature set (3) is robust and has a decent test quite(4) modify other parts of the Scala codebase that do IO to use the new functions(5) we've used in writing a few programs so that we have some understanding of what the API is really like to use
I think everything from (2) - (5), which are excellent points by the way, contradicts (1). If we make shipment with 2.8 a goal, there is a chance we will lose big, considering the 2.8 proposed timeframe (not in the far future).
I propose to leave IO in scala as is for now and not rush anything. We cannot afford to reconsider things, say in 2.9 or 3.0. At least not much and there are so many dimensions to consider.
BRChristos
--
__~O
-\ <, Christos KK Loverdos
(*)/ (*) http://ckkloverdos.com
--
http://erikengbrecht.blogspot.com/
--
__~O
-\ <, Christos KK Loverdos
(*)/ (*) http://ckkloverdos.com
Wed, 2009-09-09, 16:37
#13
Re: Scala IO Action items.
Again, FWIW, I would definitely have to vote for spending a bit of time and doing it right instead of doing it quick.
I know that 2.8 is a significant milestone and I'm sure that I'm not alone in having projects I also want to release at the same time as 2.8 final, but I don't think that haste is going to work in our favour here.
On a related note, is it worth trying to establish a post-2.8 co-ordinated release date for dependent libraries? In a similar fashion to Eclipse...
On Wed, Sep 9, 2009 at 3:59 PM, Christos KK Loverdos <loverdos@gmail.com> wrote:
I know that 2.8 is a significant milestone and I'm sure that I'm not alone in having projects I also want to release at the same time as 2.8 final, but I don't think that haste is going to work in our favour here.
On a related note, is it worth trying to establish a post-2.8 co-ordinated release date for dependent libraries? In a similar fashion to Eclipse...
On Wed, Sep 9, 2009 at 3:59 PM, Christos KK Loverdos <loverdos@gmail.com> wrote:
I'd love to be proved wrong, but think a 2.8 timeframe is unrealistic for that.
Cheers,
Miles
So Miles and I are pretty direct about that.
Guys, Scala 2.8 already incorporates both language and library changes. That should be a good indication to resist introducing more features. FWIW, I think it would make bad politics [1].
BR
Christos
[1] Always having in mind that 2.8 is intended to ship soon.
Wed, 2009-09-09, 17:57
#14
Re: Scala IO Action items.
On Wed, Sep 9, 2009 at 3:38 PM, Erik Engbrecht wrote:
> I hate to say this, but I think we need to take a step back and make sure we
> agree on our objectives. I think it's critical that:
> (1) will be shipped with 2.8
I think it's clearly too late for that. We have max 4 weeks left to
the first beta of 2.8.
So that means 2.8.1 which should be out sometimes next year.
Cheers
Wed, 2009-09-09, 19:37
#15
Re: Scala IO Action items.
I agree that there's a conflict between 1) shipping with 2.8 and 2) having feature-complete IO.
I think giving up 1) is the wrong approach.
As it exists today, Source is an abomination and an embarrassment. I'd rather see something make it into 2.8 that handles 80% of use cases (ie, isn't feature complete) but has a decent API, doesn't leak memory or resources, and allows room for growth to a feature-complete library.
For 2.8, we don't need (and don't have time for) something that matches jsr203 in features and efficiency. We can leave that for 2.later. For 2.8 we need to fix Source so that it's usable in anything but toy projects.
--j
On Wed, Sep 9, 2009 at 9:51 AM, martin odersky <martin.odersky@epfl.ch> wrote:
I think giving up 1) is the wrong approach.
As it exists today, Source is an abomination and an embarrassment. I'd rather see something make it into 2.8 that handles 80% of use cases (ie, isn't feature complete) but has a decent API, doesn't leak memory or resources, and allows room for growth to a feature-complete library.
For 2.8, we don't need (and don't have time for) something that matches jsr203 in features and efficiency. We can leave that for 2.later. For 2.8 we need to fix Source so that it's usable in anything but toy projects.
--j
On Wed, Sep 9, 2009 at 9:51 AM, martin odersky <martin.odersky@epfl.ch> wrote:
On Wed, Sep 9, 2009 at 3:38 PM, Erik Engbrecht<erik.engbrecht@gmail.com> wrote:
> I hate to say this, but I think we need to take a step back and make sure we
> agree on our objectives. I think it's critical that:
> (1) will be shipped with 2.8
I think it's clearly too late for that. We have max 4 weeks left to
the first beta of 2.8.
So that means 2.8.1 which should be out sometimes next year.
Cheers
Wed, 2009-09-09, 19:47
#16
Re: Scala IO Action items.
On 9 Sep 2009, at 19:29, Jorge Ortiz wrote:
> I agree that there's a conflict between 1) shipping with 2.8 and 2)
> having feature-complete IO.
>
> I think giving up 1) is the wrong approach.
>
> As it exists today, Source is an abomination and an embarrassment.
> I'd rather see something make it into 2.8 that handles 80% of use
> cases (ie, isn't feature complete) but has a decent API, doesn't
> leak memory or resources, and allows room for growth to a feature-
> complete library.
Putting something that isn't complete into production before it's been
ready is often the road to future disappointment. (Examples include
java.lang.Vector and friends, pretty much anything to do with Dates,
the lack of modularisation ... )
Rather than trying to rush something in, wouldn't it be better to
develop and improve it in parallel and then deploy later? After all,
part of the goal of modularisation is to encourage the thought that
modules can be updated independently rather than one big uber release.
Anyway, there's no word on when 2.9 might be around the corner; it
might not be too far in the future. Who knows? But rushing a release
has historically never worked very well in any language.
> I think it's clearly too late for that. We have max 4 weeks left to
> the first beta of 2.8.
>
> So that means 2.8.1 which should be out sometimes next year.
One of the other points I raised in the modularisation requirements is
an agreed use of version numbering. Should new functionality be
included in a 2.8.x release? If so, aren't we just like Java (but with
2 as the major number instead of 1 ...)
Alex
Wed, 2009-09-09, 20:07
#17
Re: Scala IO Action items.
Thankfully, the decision to put something that isn't complete into production has been made for us. It's called scala.io.Source and it's been a part of Scala since at least version 1.4 (!!!).
Can we just consider this a long overdue bug fix?
--j
On Wed, Sep 9, 2009 at 11:46 AM, Alex Blewitt <alex.blewitt@gmail.com> wrote:
Can we just consider this a long overdue bug fix?
--j
On Wed, Sep 9, 2009 at 11:46 AM, Alex Blewitt <alex.blewitt@gmail.com> wrote:
On 9 Sep 2009, at 19:29, Jorge Ortiz wrote:
I agree that there's a conflict between 1) shipping with 2.8 and 2) having feature-complete IO.
I think giving up 1) is the wrong approach.
As it exists today, Source is an abomination and an embarrassment. I'd rather see something make it into 2.8 that handles 80% of use cases (ie, isn't feature complete) but has a decent API, doesn't leak memory or resources, and allows room for growth to a feature-complete library.
Putting something that isn't complete into production before it's been ready is often the road to future disappointment. (Examples include java.lang.Vector and friends, pretty much anything to do with Dates, the lack of modularisation ... )
Rather than trying to rush something in, wouldn't it be better to develop and improve it in parallel and then deploy later? After all, part of the goal of modularisation is to encourage the thought that modules can be updated independently rather than one big uber release.
Anyway, there's no word on when 2.9 might be around the corner; it might not be too far in the future. Who knows? But rushing a release has historically never worked very well in any language.
I think it's clearly too late for that. We have max 4 weeks left to
the first beta of 2.8.
So that means 2.8.1 which should be out sometimes next year.
One of the other points I raised in the modularisation requirements is an agreed use of version numbering. Should new functionality be included in a 2.8.x release? If so, aren't we just like Java (but with 2 as the major number instead of 1 ...)
Alex
Wed, 2009-09-09, 20:47
#18
Re: Scala IO Action items.
Is there any reason why scala.io snapshots can't be released early as a separate jar, then merged back into scala core for the next release?
That way, folks can still have the reassurance that they're using s stable supported scala release and minimize exposure to bleeding-edge stuff in the io library.
On Wed, Sep 9, 2009 at 8:03 PM, Jorge Ortiz <jorge.ortiz@gmail.com> wrote:
That way, folks can still have the reassurance that they're using s stable supported scala release and minimize exposure to bleeding-edge stuff in the io library.
On Wed, Sep 9, 2009 at 8:03 PM, Jorge Ortiz <jorge.ortiz@gmail.com> wrote:
Thankfully, the decision to put something that isn't complete into production has been made for us. It's called scala.io.Source and it's been a part of Scala since at least version 1.4 (!!!).
Can we just consider this a long overdue bug fix?
--j
On Wed, Sep 9, 2009 at 11:46 AM, Alex Blewitt <alex.blewitt@gmail.com> wrote:
On 9 Sep 2009, at 19:29, Jorge Ortiz wrote:
I agree that there's a conflict between 1) shipping with 2.8 and 2) having feature-complete IO.
I think giving up 1) is the wrong approach.
As it exists today, Source is an abomination and an embarrassment. I'd rather see something make it into 2.8 that handles 80% of use cases (ie, isn't feature complete) but has a decent API, doesn't leak memory or resources, and allows room for growth to a feature-complete library.
Putting something that isn't complete into production before it's been ready is often the road to future disappointment. (Examples include java.lang.Vector and friends, pretty much anything to do with Dates, the lack of modularisation ... )
Rather than trying to rush something in, wouldn't it be better to develop and improve it in parallel and then deploy later? After all, part of the goal of modularisation is to encourage the thought that modules can be updated independently rather than one big uber release.
Anyway, there's no word on when 2.9 might be around the corner; it might not be too far in the future. Who knows? But rushing a release has historically never worked very well in any language.
I think it's clearly too late for that. We have max 4 weeks left to
the first beta of 2.8.
So that means 2.8.1 which should be out sometimes next year.
One of the other points I raised in the modularisation requirements is an agreed use of version numbering. Should new functionality be included in a 2.8.x release? If so, aren't we just like Java (but with 2 as the major number instead of 1 ...)
Alex
Wed, 2009-09-09, 21:07
#19
Re: Scala IO Action items.
On Wed, Sep 9, 2009 at 8:43 PM, Kevin
Wright wrote:
> Is there any reason why scala.io snapshots can't be released early as a
> separate jar, then merged back into scala core for the next release?
>
> That way, folks can still have the reassurance that they're using s stable
> supported scala release and minimize exposure to bleeding-edge stuff in the
> io library.
Why can't prototypes continue to live under scalax.io (or whatever)
until we've got something that's suitable for inclusion in the
standard library?
We should guard the scala.* prefix at least as carefully as the java.*
prefix has been.
Cheers,
Miles
Wed, 2009-09-09, 21:57
#20
Re: Scala IO Action items.
Also, an 80% solution does not necessarily mean a half-baked solution. Often times it's the extra 10-20% that introduces the half-bakedness.
I also think that if we shoot for having a solidly implemented subset of the overall functionality beta-level in three weeks I think we'll be in a lot better shape than if we debate for three weeks. The worst that happens is we look at it and decide it just isn't ready. We shouldn't do the work in trunk, although we should follow trunk. That way it will be easy to merge in if/when it become appropriate, and we don't have to worry about pulling it out.
On Wed, Sep 9, 2009 at 3:03 PM, Jorge Ortiz <jorge.ortiz@gmail.com> wrote:
--
http://erikengbrecht.blogspot.com/
I also think that if we shoot for having a solidly implemented subset of the overall functionality beta-level in three weeks I think we'll be in a lot better shape than if we debate for three weeks. The worst that happens is we look at it and decide it just isn't ready. We shouldn't do the work in trunk, although we should follow trunk. That way it will be easy to merge in if/when it become appropriate, and we don't have to worry about pulling it out.
On Wed, Sep 9, 2009 at 3:03 PM, Jorge Ortiz <jorge.ortiz@gmail.com> wrote:
Thankfully, the decision to put something that isn't complete into production has been made for us. It's called scala.io.Source and it's been a part of Scala since at least version 1.4 (!!!).
Can we just consider this a long overdue bug fix?
--j
On Wed, Sep 9, 2009 at 11:46 AM, Alex Blewitt <alex.blewitt@gmail.com> wrote:
On 9 Sep 2009, at 19:29, Jorge Ortiz wrote:
I agree that there's a conflict between 1) shipping with 2.8 and 2) having feature-complete IO.
I think giving up 1) is the wrong approach.
As it exists today, Source is an abomination and an embarrassment. I'd rather see something make it into 2.8 that handles 80% of use cases (ie, isn't feature complete) but has a decent API, doesn't leak memory or resources, and allows room for growth to a feature-complete library.
Putting something that isn't complete into production before it's been ready is often the road to future disappointment. (Examples include java.lang.Vector and friends, pretty much anything to do with Dates, the lack of modularisation ... )
Rather than trying to rush something in, wouldn't it be better to develop and improve it in parallel and then deploy later? After all, part of the goal of modularisation is to encourage the thought that modules can be updated independently rather than one big uber release.
Anyway, there's no word on when 2.9 might be around the corner; it might not be too far in the future. Who knows? But rushing a release has historically never worked very well in any language.
I think it's clearly too late for that. We have max 4 weeks left to
the first beta of 2.8.
So that means 2.8.1 which should be out sometimes next year.
One of the other points I raised in the modularisation requirements is an agreed use of version numbering. Should new functionality be included in a 2.8.x release? If so, aren't we just like Java (but with 2 as the major number instead of 1 ...)
Alex
--
http://erikengbrecht.blogspot.com/
Wed, 2009-09-09, 22:17
#21
Re: Scala IO Action items.
On Wed, Sep 9, 2009 at 9:56 PM, Erik Engbrecht wrote:
> I also think that if we shoot for having a solidly implemented subset of the
> overall functionality beta-level in three weeks I think we'll be in a lot
> better shape than if we debate for three weeks. The worst that happens is
> we look at it and decide it just isn't ready. We shouldn't do the work in
> trunk, although we should follow trunk. That way it will be easy to merge
> in if/when it become appropriate, and we don't have to worry about pulling
> it out.
I recommend doing this outside the scala.* package hierarchy, ie. as
an independent library, so that it's easy to distribute and use for
evaluation. If it works out well then renaming into scala.* would be
trivial.
Cheers,
Miles
Wed, 2009-09-09, 22:57
#22
Re: Scala IO Action items.
I think that would make sense if we abandoned the objective of getting something good into 2.8, but if we continue to pursue that objective then it add schedule pressure because there will be the work to merge it into the Scala namespace and update various bits and pieces of the Scala compiler and standard library to use it instead of/in addition to Java APIs. Having it in a separate namespace also makes it easier to evaluate how the changes fit into the big picture, and would allow us to make any needed tweaks to APIs in other parts of the library (which could be merged back independently).
In the event that it's not ready for inclusion, then we should pull in out into a separate namespace. I think pulling it out of scala and into scalax will be easier than the reverse.
I'll also point out that we already tried doing this in scalax. Very few people paid attention (thank you very much to the people who did) until (1) Paul started making changes to trunk and (2) I brought the discussion about Paul's commits and various design decisions to scala-internals. Small discussions had been happening on IRC and the scalax mailing list for a couple months before that.
Consequently, I'm concerned that if we don't have a short term goal, with decent incentive to complete (e.g. inclusion in 2.8), and working code all along the way people are just going to lose interest and nothing will happen.
On Wed, Sep 9, 2009 at 5:07 PM, Miles Sabin <miles@milessabin.com> wrote:
--
http://erikengbrecht.blogspot.com/
In the event that it's not ready for inclusion, then we should pull in out into a separate namespace. I think pulling it out of scala and into scalax will be easier than the reverse.
I'll also point out that we already tried doing this in scalax. Very few people paid attention (thank you very much to the people who did) until (1) Paul started making changes to trunk and (2) I brought the discussion about Paul's commits and various design decisions to scala-internals. Small discussions had been happening on IRC and the scalax mailing list for a couple months before that.
Consequently, I'm concerned that if we don't have a short term goal, with decent incentive to complete (e.g. inclusion in 2.8), and working code all along the way people are just going to lose interest and nothing will happen.
On Wed, Sep 9, 2009 at 5:07 PM, Miles Sabin <miles@milessabin.com> wrote:
On Wed, Sep 9, 2009 at 9:56 PM, Erik Engbrecht<erik.engbrecht@gmail.com> wrote:
> I also think that if we shoot for having a solidly implemented subset of the
> overall functionality beta-level in three weeks I think we'll be in a lot
> better shape than if we debate for three weeks. The worst that happens is
> we look at it and decide it just isn't ready. We shouldn't do the work in
> trunk, although we should follow trunk. That way it will be easy to merge
> in if/when it become appropriate, and we don't have to worry about pulling
> it out.
I recommend doing this outside the scala.* package hierarchy, ie. as
an independent library, so that it's easy to distribute and use for
evaluation. If it works out well then renaming into scala.* would be
trivial.
Cheers,
Miles
--
Miles Sabin
tel: +44 (0)7813 944 528
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin
--
http://erikengbrecht.blogspot.com/
Wed, 2009-09-09, 23:07
#23
Re: Scala IO Action items.
On Wed, Sep 9, 2009 at 10:55 PM, Erik Engbrecht wrote:
> I'll also point out that we already tried doing this in scalax. Very few
> people paid attention
I think at least part of that problem was the where the discussion was
happening: as we've seen in the last few days, discussion on an
offical list gets more and more useful attention.
Cheers,
Miles
Thu, 2009-09-10, 02:27
#24
Re: Scala IO Action items.
Yes, but you can't discuss an external library's internal implementation details on an official list, or at least I didn't think you were supposed to.
If scalax.io becomes the feeder for scala.io, and we base a SID off of it, then yes discussions should be somewhere scala-official. However, as we were trying to update scalax.io, that's where our focus was. Anyway, the past is in the past. I say we creating a working group that works on scala.io.
I propose the following:
1) We set up a scala.io working group. Members who join must sign the EPFL contributor agreement.
2) We continue using scala-internals, or set up our own mailing list.
3) We work off a project in github. Perhaps we keep the library in the scalax namespace so people can try it out.
4) We should not let scala.io.Source stand alone. I'd like to at least improve this slightly before 2.8 if possible. We have pieces that we know are useful from scalax.io. I don't see the harm in including a few of the non-invasive APIs and mark them as "experimental" (or undocumented) like scala.reflect.Manifest.
5) Instead of having a final release targeting 2.8 (which is liking trying to hit a moving bus), we should have milestone goals that include specific dates. I also don't see the issue with improving the IO in the scala-library and marking it as "experimental" or "not complete" so people can expect change, but at least aren't relegated to using home-grown solutions or java.
6) The resulting library should be wholey scala. It needs to look and feel like a scala API. I hate using thin-java-library wrappers that don't take into account scala idioms. When taking real advantage of Scala features, it integrates better with the rest of the langauge, and looks more like a "core" library.
7) Before creating a conmitte we also need a way of resolving disputes, Something besides "the loudest voice wins". I suggest we do a system where comittee members can vote, and a qurom needs to be reached before a SID (and accompanying library) is passed.
8) I also think the comittee needs a "chairman". Someone to start votes, ensure milestones are reached and enforce fairness.
Anyway, the scala lift of in Reston, VA is a month and a half away. Perhaps those of us interested could meet there? Martin, Erik and I will be there, of others would like to attend, please let me know.
- Josh
On Wed, Sep 9, 2009 at 6:03 PM, Miles Sabin <miles@milessabin.com> wrote:
If scalax.io becomes the feeder for scala.io, and we base a SID off of it, then yes discussions should be somewhere scala-official. However, as we were trying to update scalax.io, that's where our focus was. Anyway, the past is in the past. I say we creating a working group that works on scala.io.
I propose the following:
1) We set up a scala.io working group. Members who join must sign the EPFL contributor agreement.
2) We continue using scala-internals, or set up our own mailing list.
3) We work off a project in github. Perhaps we keep the library in the scalax namespace so people can try it out.
4) We should not let scala.io.Source stand alone. I'd like to at least improve this slightly before 2.8 if possible. We have pieces that we know are useful from scalax.io. I don't see the harm in including a few of the non-invasive APIs and mark them as "experimental" (or undocumented) like scala.reflect.Manifest.
5) Instead of having a final release targeting 2.8 (which is liking trying to hit a moving bus), we should have milestone goals that include specific dates. I also don't see the issue with improving the IO in the scala-library and marking it as "experimental" or "not complete" so people can expect change, but at least aren't relegated to using home-grown solutions or java.
6) The resulting library should be wholey scala. It needs to look and feel like a scala API. I hate using thin-java-library wrappers that don't take into account scala idioms. When taking real advantage of Scala features, it integrates better with the rest of the langauge, and looks more like a "core" library.
7) Before creating a conmitte we also need a way of resolving disputes, Something besides "the loudest voice wins". I suggest we do a system where comittee members can vote, and a qurom needs to be reached before a SID (and accompanying library) is passed.
8) I also think the comittee needs a "chairman". Someone to start votes, ensure milestones are reached and enforce fairness.
Anyway, the scala lift of in Reston, VA is a month and a half away. Perhaps those of us interested could meet there? Martin, Erik and I will be there, of others would like to attend, please let me know.
- Josh
On Wed, Sep 9, 2009 at 6:03 PM, Miles Sabin <miles@milessabin.com> wrote:
On Wed, Sep 9, 2009 at 10:55 PM, Erik Engbrecht<erik.engbrecht@gmail.com> wrote:
> I'll also point out that we already tried doing this in scalax. Very few
> people paid attention
I think at least part of that problem was the where the discussion was
happening: as we've seen in the last few days, discussion on an
offical list gets more and more useful attention.
Cheers,
Miles
--
Miles Sabin
tel: +44 (0)7813 944 528
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin
Thu, 2009-09-10, 10:17
#25
Re: Scala IO Action items.
I think the best option is to publish the core of I/O library as soon
as is feasible, as part of Lift.
Once it has matured a bit, we'll move it into the distribution. I
agree io.SourceFile is a disgrace, but one thing at a time...
Cheers
On Wed, Sep 9, 2009 at 9:06 AM, Jesse Eichar wrote:
> Comments?
Excellent stuff ...
Cheers,
Miles