Bob Rogers wrote:
From: Joshua Isom <[EMAIL PROTECTED]>
Date: Fri, 6 Jan 2006 23:53:51 -0600
On Jan 6, 2006, at 10:17 PM, Joshua Juran wrote:
> On Jan 6, 2006, at 4:11 PM, Alberto Simoes via RT wrote:
>
>> This needs some more discussion. If we look to Perl, for instance, it
>> doesn't have a built-in copy. You should use either a module, or open
>> both files, copy contents, and close both files.
>
> You assume cp semantics. What about preserving metadata? What about
> multiple forks? What about per-file properties that are invented
> after you ship your code? And what if the source and destination are
> on the same file server?
So it'd probably be best to put it in os.pmc with checks to know which
operating system it's compiled for. That way, each language
implementation that includes an operator to copy a file can do so more
safely. Isn't part of the point of parrot to make writing a compiler
not be system dependent? In fact, if perl had a copy operator instead
of doing the open/print combo, the resource fork issue on Macs would be
taken care of.
Thinking in another direction, why is there only one OS class? Seems to
me it would be cleaner to implement such things as file copy if there
were a class hierarchy that reflected OS family relationships.
Even more importantly, having multiple classes would make it much
easier for language implementors to define OS-independent interfaces for
language-specific features. This would then be a simple matter of
writing multimethods that dispatch on the right OS subclasses, without
worrying about which class actually gets instantiated.
I think we might have a bigger problem than a copy per OS. I think we
will have a copy per FileSystem if we get too detailed in its process.
Alberto
--
Alberto Simões - Departamento de Informática - Universidade do Minho
Campus de Gualtar - 4710-057 Braga - Portugal
