Smalltalk › Pharo › Pharo Smalltalk Developers

why FileDirectory sucks

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

26 messages Options

Michael Rueger-6

Re: why FileDirectory sucks

Stéphane Ducasse wrote:
>> Well actually in Sophie we used URI http://en.wikipedia.org/wiki/URI
>> *hint* all that code is MIT
>
> I know I just did not find time....
> Good I do not know why a moment I thought that the sophie license was
> different.

It actually is. New BSD, which is basically MIT with the advertising clause.
So if we add code from Sophie (other than fixes) we would need to list
the new BSD license as well.

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

johnmci

Re: why FileDirectory sucks

On 1-Jul-09, at 4:02 PM, Michael Rueger wrote:

> It actually is. New BSD, which is basically MIT with the advertising
> clause.
> So if we add code from Sophie (other than fixes) we would need to list
> the new BSD license as well.
>
> Michael

I must turn the A/C up another notch before talking about licensing
issues without rechecking...
Grab some ice water, goodness knows we don't need another license
thread...

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]> Twitter:
squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
========================================================================

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

johnmci

Re: why FileDirectory sucks

In reply to this post by Stephen Pair

I think there is a whole day of reading on the squeak list now about
backwards forward compatibility if you
change the meaning of FileSystem default defaultDirectory and have it
return a URI, that would break things, or
assumptions etc.

Personally I'd think it should be

URI defaultFileSystemDirectory

and others, temp, document, vm, etc..

Er so FileSystem default defaultDirectory
would really do

^URI defaultFileSystemDirectory absolutePath

On 1-Jul-09, at 4:01 PM, Stephen Pair wrote:

>
>
> On Wed, Jul 1, 2009 at 5:32 PM, Michael Rueger <[hidden email]>
> wrote:
> Igor Stasenko wrote:
>
> > how then i could write a 'FileDirectory default' in terms of URIs?
> > 'file://.' asURI ?
>
> No, you would still write FileDirectory default :-)
>
> But then you would do something like
>
> (FileDirectory default uri resolveRelativePath: 'myDir/images')
> directory
>
> I think I would obliterate FileDirectory and write something more
> like "FileSystem default defaultDirectory", which would answer a URI.
>
> - Stephen

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]> Twitter:
squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
========================================================================

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

hernanmd

Re: why FileDirectory sucks

In reply to this post by Igor Stasenko

2009/7/1 Igor Stasenko <[hidden email]>:

> 2009/7/1 Michael Rueger <[hidden email]>:
>> Stephen Pair wrote:
>>
>>> accomplish this (in VisualWorks). It would be really cool if things
>>> like filenames and directories didn't make assumptions about the file
>>> system with which they are used (so that you could have filenames for in
>>> memory file systems, or filenames for other file systems that one might
>>> connect with in ways other than the built in local file system primitives).
>>
>> broken record... ;-)
>>
>> ...use URIs :-)
>>
> how then i could write a 'FileDirectory default' in terms of URIs?
> 'file://.' asURI ?

Path @ 'file://'
Path @ 'file://c:\file.txt'
( Path @ 'file://c:\file.txt' ) readStream contents.
( Path @ 'file://c:\file.txt' ) writeStream.
( Path @ 'http://www.dreamtheater.net/' ) readStream contents.
( Path @ 'app://yourContainer1.yourContainer2.yourObject' ) readStream
etc.

>
>> Then send things like stream, writeStream etc to the URI and have the
>> scheme dispatch resolve the rest.
>>
>> Michael
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stéphane Ducasse

Re: why FileDirectory sucks

In reply to this post by Michael Rueger-6

Ok I also like some parts of the rio api.
Arg too much to do.

Stef

On Jul 1, 2009, at 11:32 PM, Michael Rueger wrote:

> Igor Stasenko wrote:
>
>> how then i could write a 'FileDirectory default' in terms of URIs?
>> 'file://.' asURI ?
>
> No, you would still write FileDirectory default :-)
>
> But then you would do something like
>
> (FileDirectory default uri resolveRelativePath: 'myDir/images')
> directory
>
> I know, doesn't look to elegant, but it's of context you rarely really
> work with directories, but rather paths.
>
> Also take into account the FileLocations package which gives you calls
> for userDataURI, tempURI etc, allowing to transparently integrate with
> you platform specific paths.
>
> Michael
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

David Goehrig

Re: why FileDirectory sucks

Pharoers,

In my image I have a few methods that make file access a little more legible:

Http // 'www.slashdot.org/'

File // '/Users/dave/hello.c'

It reads just like a protocol string :)

Both of these class methods return a ByteString, what I typically need 99% of the time. When I need a stream for some strange reason:

ReadStream on: (File // '/Users/dave/hello.c') .

For my needs, this approach has made file access both straight forward while remaining true to the URI semantics.

Dave

--
-=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project