This page is no longer maintained — Please continue to the home page at www.scala-lang.org

what is scala.io.File?

13 replies
anli
Joined: 2008-08-19,
User offline. Last seen 1 day 3 hours ago.

I have read this thread

http://www.scala-lang.org/node/3169
http://www.scala-lang.org/node/3186

with great interest. At the beginning. Then I have confused: what is this
discussion about?

Not being involved in the language development process I don't feel rights to
join that discussion - [scala-user] is my place :-) Please, excuse me for
opening parallel (in some sense) thread. I'll be happy to catch raw Scala
users to that discussion.

About my confusion. From my humble user's point of view, any attempts to
generalize too different islands (regular file, pipes, network sockets, unix
sockets, attributes related to different operation systems, acl/rbac,
symlinks, cryptography, ram, REST, ... continue, please) result in hardly-
usable monsters.

Probably more simple way (in learning, using and maintaining) is to keep all
these different ... well, things with their own rights (attributes,
operations). Just make these islands friendly to Scala collections and create
a way to communicate (streams).

But, well, a common view to different artefacts is a good thing! Aha-aha, I
see. And agree. But here we have a *view*. Last one (say, URI) can be added
at current context by hand, or, probably, some most common views may be added
to the library. But, at any case, all these views are based on self-contained,
clean and light artefacts.

I dream scala.io.File to be a file.

(you see, my English is ugly, but I hope you will believe me: I have not any
claims in my mind - just sharing opinion)

(Paul, revert reversion!)

Andrew

Ricky Clarkson
Joined: 2008-12-19,
User offline. Last seen 3 years 2 weeks ago.
Re: what is scala.io.File?

> Then I have confused: what is this
> discussion about?

The discussion is about providing a useful I/O library for Scala.

> About my confusion. From my humble user's point of view, any attempts to
> generalize too different islands (regular file, pipes, network sockets, unix
> sockets, attributes related to different operation systems, acl/rbac,
> symlinks, cryptography, ram, REST, ... continue, please) result in hardly-
> usable monsters.

Yet generalising over them is exactly their purpose. That's why pipes
appear as [special] files, so that utilities that know how to deal
with files can deal with pipes, for example.

Generalising *badly* results in unusable monsters, sure.

> Probably more simple way (in learning, using and maintaining) is to keep all
> these different ... well, things with their own rights (attributes,
> operations). Just make these islands friendly to Scala collections and create
> a way to communicate (streams).

You're encouraging code duplication.

> (Paul, revert reversion!)

+1

John Nilsson
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Re: what is scala.io.File?

On Tue, Sep 8, 2009 at 2:30 AM, Ricky Clarkson wrote:
> Yet generalising over them is exactly their purpose.  That's why pipes
> appear as [special] files, so that utilities that know how to deal
> with files can deal with pipes, for example.

The ideas of files as a general API is also a basic philosophy behind
the Unix architecture: "Everything is a file"[1]. In fact this idea
was so important that a successor to Unix, Plan 9 [2], was created to
drive the principle further than what Unix ever dit did.

[1] http://ph7spot.com/articles/in_unix_everything_is_a_file
[2] http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs

BR,
John

anli
Joined: 2008-08-19,
User offline. Last seen 1 day 3 hours ago.
Re: what is scala.io.File?

On Wednesday 09 September 2009 00:44:07 John Nilsson wrote:
> On Tue, Sep 8, 2009 at 2:30 AM, Ricky Clarkson
wrote:
> > Yet generalising over them is exactly their purpose. That's why pipes
> > appear as [special] files, so that utilities that know how to deal
> > with files can deal with pipes, for example.
>
> The ideas of files as a general API is also a basic philosophy behind
> the Unix architecture: "Everything is a file"[1]. In fact this idea
> was so important that a successor to Unix, Plan 9 [2], was created to
> drive the principle further than what Unix ever dit did.
>
> [1] http://ph7spot.com/articles/in_unix_everything_is_a_file
> [2] http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs
>
> BR,
> John
>

Well, I have single-boot Linux during ~7-8 years and was forced to be slightly
familiar with this concept. OTOH, I'm not sure operating system concept is
applicable to the standard language library. And, at any case, if we want to
live in "write once...", we are forced to use at most an intersection of all
these multiple concepts (I mean multiple file system concepts with all their
nuances and dialects in context of all those operating systems where JVM
exists).

Just deep interaction of few base common artefacts (file, directory and such)
with Scala collections gives us "scalized" io beauty collections already have.
If we already have collections (well, and something stream-like), why we need
more concepts to manupulate data?

All those system-dependent io nuances are matter of external libraries, aren't
they?

Andrew

John Nilsson
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Re: what is scala.io.File?

On Tue, Sep 8, 2009 at 11:09 PM, Andrew Gaydenko wrote:
> I'm not sure operating system concept is
> applicable to the standard language library.
I don't know, I guess there is some lessons to be learned. The design
of HTTP seems mildly based on the same conceptual idea, and just see
how wildly popular that API turned out to be! =)

OTOH, "Everything is an object" might work just as well given the right touch.

But I guess you are right in that there is a difference between
library design, and design of core abstractions, especially if any
attempt at abstracting away platform differences is doomed to be
leaky.

I don't think files in Unix can have multiple streams f.ex. but that
is allowed in NTFS IIUC, and the mac filesystem does dome wierd things
with metadata in files.

BR,
John

Ricky Clarkson
Joined: 2008-12-19,
User offline. Last seen 3 years 2 weeks ago.
Re: what is scala.io.File?

Yes, it might be useful sometimes to expose operations that are
specific to certain types of file. However, those are the exception
rather than the rule. The rule is "abstraction wins", because none of
us wants to write separate code for reading from a symlink than from
reading from a regular file or a special file. I find it strange that
a programmer objects to abstraction.

2009/9/8 Andrew Gaydenko :
> On Wednesday 09 September 2009 00:44:07 John Nilsson wrote:
>> On Tue, Sep 8, 2009 at 2:30 AM, Ricky Clarkson
> wrote:
>> > Yet generalising over them is exactly their purpose.  That's why pipes
>> > appear as [special] files, so that utilities that know how to deal
>> > with files can deal with pipes, for example.
>>
>> The ideas of files as a general API is also a basic philosophy behind
>> the Unix architecture: "Everything is a file"[1]. In fact this idea
>> was so important that a successor to Unix, Plan 9 [2], was created to
>> drive the principle further than what Unix ever dit did.
>>
>> [1]
http://ph7spot.com/articles/in_unix_everything_is_a_file
>> [2] http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs
>>
>> BR,
>> John
>>
>
> Well, I have single-boot Linux during ~7-8 years and was forced to be slightly
> familiar with this concept. OTOH, I'm not sure operating system concept is
> applicable to the standard language library. And, at any case, if we want to
> live in "write once...", we are forced to use at most an intersection of all
> these multiple concepts (I mean multiple file system concepts with all their
> nuances and dialects in context of all those operating systems where JVM
> exists).
>
> Just deep interaction of few base common artefacts (file, directory and such)
> with Scala collections gives us "scalized" io beauty collections already have.
> If we already have collections (well, and something stream-like), why we need
> more concepts to manupulate data?
>
> All those system-dependent io nuances are matter of external libraries, aren't
> they?
>
>
> Andrew
>

Ricky Clarkson
Joined: 2008-12-19,
User offline. Last seen 3 years 2 weeks ago.
Re: what is scala.io.File?
John Nilsson
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Re: what is scala.io.File?

On Tue, Sep 8, 2009 at 11:25 PM, Ricky Clarkson wrote:
> If you seriously want to design a library to take account of all those issues:
>
> 1. Look at Common Lisp's I/O stuff.  It abstracts around all sorts of
> filesystem oddities, most of which most programmers never see.
> Unfortunately, it loses a bit of simplicity for normal use, but I
> imagine that could be improved upon.

Thanks for the tip. Will have a look.

Without having done so yet, maybe this is supposed to be done at three layers

Layer one is platform specific APIs to expose all odd features.
Layer two is the common file as a stream API
Layer three uses layer one to implement highlevel stuff like file
types and their specifics, document meta data, application launchers,
icons and other common meta data operation.

BR,
John

anli
Joined: 2008-08-19,
User offline. Last seen 1 day 3 hours ago.
Re: what is scala.io.File?

On Wednesday 09 September 2009 01:16:14 you wrote:
> Yes, it might be useful sometimes to expose operations that are
> specific to certain types of file. However, those are the exception
> rather than the rule. The rule is "abstraction wins", because none of
> us wants to write separate code for reading from a symlink than from
> reading from a regular file or a special file. I find it strange that
> a programmer objects to abstraction.

No-no, I don't object :-) I'm saying about abstraction *degree* only.

There are plenty of fine ideas. Sometimes we want to express these ideas in
this or that form, and forget our aim - to do some concrete thing. But simple
tasks, I guess, must be kept simple. Abstractions are for pleasing dealing
with concrete things, rather things exist to express beautyful abstractions.

"abstraction wins"? Not inevitably, ptobably. Say, how many excellent - and
dead now - protocols were designed?

BTW, what is ARM? Someething like "Abstract Resources Management"? Or what? I
have noticed this abbreviation in [internals] list.

loverdos
Joined: 2008-11-18,
User offline. Last seen 2 years 27 weeks ago.
Re: what is scala.io.File?

>
> BTW, what is ARM? Someething like "Abstract Resources Management"?
> Or what? I
> have noticed this abbreviation in [internals] list.

Automatic resource management?

Erik Engbrecht
Joined: 2008-12-19,
User offline. Last seen 3 years 18 weeks ago.
Re: what is scala.io.File?
Bingo.  You win the prize!

On Tue, Sep 8, 2009 at 6:20 PM, Christos KK Loverdos <loverdos [at] gmail [dot] com> wrote:

BTW, what is ARM? Someething like "Abstract Resources Management"? Or what? I
have noticed this abbreviation in [internals] list.

Automatic resource management?

anli
Joined: 2008-08-19,
User offline. Last seen 1 day 3 hours ago.
Re: what is scala.io.File?

On Wednesday 09 September 2009 02:34:31 Erik Engbrecht wrote:
> Bingo. You win the prize!

:-) Aha, I see, non-prevailing must read, say, here:

http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000011.html

loverdos
Joined: 2008-11-18,
User offline. Last seen 2 years 27 weeks ago.
Re: what is scala.io.File?
Haha, ok!
Believe it or not, when I saw ARM in the thread I could not, for a while grok it. Sometimes the brain just gets stuck.
I had a discussion recently with a friend about old computers and I told him about an Acorn Archimedes I had seen about twenty years ago, that had an ARM RISC processor and whose BASIC was blazingly fast at 4MHz clock speed.
So _that_ ARM got stuck for a while, even at this particular (IO-related) context.
Christos

On Sep 9, 2009, at 01:34, Erik Engbrecht wrote:
Bingo.  You win the prize!

On Tue, Sep 8, 2009 at 6:20 PM, Christos KK Loverdos <loverdos [at] gmail [dot] com> wrote:

BTW, what is ARM? Someething like "Abstract Resources Management"? Or what? I
have noticed this abbreviation in [internals] list.

Automatic resource management?

--
  __~O
 -\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com









--
http://erikengbrecht.blogspot.com/

-- 
   __~O
  -\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com





anli
Joined: 2008-08-19,
User offline. Last seen 1 day 3 hours ago.
Re: what is scala.io.File?

OK, jsr223 and ARM are great - and rather longterm - things. I still try to
imagine this or that palliative - to take to Scala users' hands useful file-
related API in terms of 2.8. Probably Paul's io work can be moved (and
modified if needed) to new package like scala.filesystem (or scala.fs). During
that big scala.io development scala.fs can be then (partly) reimplemented
and/or refined to be in accordance with scala.io (or, reversing, used by
scala.io).

I understand, any API opening is very fragile step.

What do you think?

And, BTW, are there intentions to deprecate current scala.io?

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland