Including files

At 05:24 PM 9/25/2006 +0200, Bonzini Paolo wrote:
Thanks.

Why is it that File isn't a subclass of RealFileSystem.

>
>Paolo



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

J Pfersich wrote:
>
> Why is it that File isn't a subclass of RealFileSystem.

Because it could be contained (not extracted) within an archive, or on a
remote server.

I must say that I don't think that the classes File and Directory have a
very clear idea of what they *are*, though.

To take some examples, it seems clear to me that Directory class >>
#working should return a Directory and not a String, and that Directory
>> contents should return a collection of Files. Unfortunately, in the
latter case it becomes difficult to pick out '.' and '..' (since you
usually want to ignore them).

Mike


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Mike Anderson wrote:
> J Pfersich wrote:
>  
>> Why is it that File isn't a subclass of RealFileSystem.
>>    
File is an adaptor for VFSHandler, of which RealFileSystem is a subclass.
> I must say that I don't think that the classes File and Directory have a
> very clear idea of what they *are*, though.
>  
I agree, though I'm not sure if I want to break compatibility now.  If
we get a 3.0 we could think about it.
> latter case it becomes difficult to pick out '.' and '..' (since you
> usually want to ignore them).
Directory>>#contents may blow them up itself, if we are to change the
interface...

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Paolo Bonzini wrote:
> Mike Anderson wrote:
>
>> I must say that I don't think that the classes File and Directory have a
>> very clear idea of what they *are*, though.
>
> I agree, though I'm not sure if I want to break compatibility now.  If
> we get a 3.0 we could think about it.

Yes (although what do you think about a loadable package in examples or
unsupported?).

>> latter case it becomes difficult to pick out '.' and '..' (since you
>> usually want to ignore them).
>
> Directory>>#contents may blow them up itself, if we are to change the
> interface...

Good point (I think I'll apply that to my 'comfort' package right now),
although I think there is a larger problem, which is that Files don't
remember if they were created with a relative path.

Mike


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> Yes (although what do you think about a loadable package in examples or
> unsupported?).
>  
Yes, why not.  Just a file-in in unsupported would be great (with the
plan to merge it later on).  Actually File/Directory started in
unsupported (when I was not maintainer and it was not yet called
unsupported...).  And alas when I moved it out of unsupported, I really
forget to think about a proper design. :-( We just need a Directory stored in an instance variable for that.  That
would not break backwards compatibility.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk