Buddha Buck wrote:
On Thu, Jul 9, 2009 at 9:32 PM, Darren Duncan<dar...@darrenduncan.net> wrote:
Mark J. Reed wrote:
A few months ago (or maybe more) I proposed making pathnames their own
type, distinct from (or perhas a subclass of) strings, but easily
constructed from strings, maybe with an operator. Having those 29
single-letter methods on such a class would not bug me as much as
having them on Str.
On 7/9/09, Aristotle Pagaltzis <pagalt...@gmx.de> wrote:
* Moritz Lenz <mor...@faui2k3.org> [2009-07-10 00:25]:
stat($str, :e) # let multi dispatch handle it for us
This gets my vote.
I agree. The built-ins of basic types like Str or Int etc need to stay pure
and just be about dealing with local data. Having methods on basic types
for going out into the wider environment like the file system is just plain
wrong. There should be separate IO classes for things like stat, which
*use* basic types like Str for their interface definitions, and the full
definition of Str/etc should not include any file-system operations.
It's unclear which you are agreeing with. By reference, it sounds
like you agree with the idea of a separate pathname type, but by
context, it sounds like you are agreeing with stat($str, :e)
Both the separate pathname type and the stat($str, :e) proposal
salvage the purity of Str, so either would be acceptable to your
argument.
I don't see an ambiguity.
I am saying that the Str class should not have filesystem methods.
Routines like stat() should either be methods of a quasi-singleton FileSystem
class, or they should be subroutines in a non-OO FileSystem module.
Either way, a file name can still be represented by a Str.
Now I'm not against a distinct Filename type, in fact I'm sure its a good idea,
but I do think that users shouldn't have to use one explicitly if they don't
want to. Eg, "FileSystem.stat($str, :e)" should just DWIM.
But my main point is still that stat() etc should not be methods of Str.
-- Darren Duncan
