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. My $0.02, -- Bob Rogers http://rgrjr.dyndns.org/