On Fri, Apr 15, 2005 at 01:12:46PM -0700, Michael G Schwern wrote:
: Thus spake Larry Wall:
: > Offhand, I guess my main semantic problem with it is that if a chdir
: > fails, you aren't in an undefined location, which the new value of $CWD
: > would seem to indicate. You're just where you were. Then the user
: > either has to remember that, or there still has to be some other
: > means of finding out the real location.
:
: To be clear: Only the store operation will return undef on failure.
That doesn't square with the notion that an assignment returns the
actual lvalue:
($new = $old) =~ s/foo/bar/;
: Additional fetches on $CWD will continue to return the cwd.
:
: $CWD = '/path/which/exists';
: $CWD = '/i/do/not/exist' err warn $!;
: print $CWD;
:
: This prints /path/which/exists/.
Except that the err should be looking at $CWD, not some other return value
of the assignment.
: > The other problem with it is the fact that people will assign relative
: > paths to it and expect to get the relative path back out instead
: > of the absolute path.
:
: I honestly never had this problem until I sat down and thought about it. :)
: THEN I got all confused and started to do things like $CWD .= '/subdir';
: instead of simply $CWD = 'subdir';. But the rule is simple and natural.
: It takes a relative or absolute directory and ALWAYS returns an absolute
: path. Lax in what inputs it accepts, strict in what it emits. This is no
: more to remember than what chdir() and cwd() would do.
:
: The result from $CWD would simply be a Dir object similar to Ken Williams'
: Path::Class or Ruby's Dir object. One of the methods would be .relative.
:
: I didn't bring up @CWD because I thought it would be too much in one sitting.
: Basically it allows you to do this:
:
: pop @CWD; # chdir ('..');
: push @CWD, 'dir'; # chdir ('dir');
: print $CWD[0]; # (File::Spec->splitdir(abs_path()))[0];
: # ie. What top level directory am I in?
:
: and all sorts of other operations that would normally involve a lot of
: splitdir'ing.
:
: And then there's %CWD which I'm toying with being a per-volume chdir like
: you can do on Windows but that may be too much of a questionable thing.
You could multiplex both the array and hash roles into the object
returned by $CWD, much like the $/ pattern match result object can
be subscripted as either $/[1] or $/<mantissa>. $CWD would itself
behave like a string in string context, but $CWD[] would get you to
the array value, and $CWD{} the hash value for systems that have
more than one current directory.
: > Your assumption there is a bit inaccurate--in P6 you are allowed to
: > temporize (localize) the effects of functions and methods that are
: > prepared to deal with it.
:
: Yeah, we were talking about it on #perl6 a bit. That seems to me the more
: bizarre idea than assigning to something which can fail. Localizing an
: assignment is easy, there's just one thing to revert. But function calls can
: do lots of things. Just how much does it reverse? I guess if its used
: sensibly on sharp functions, such as chdir, and the behavior is
: user-definable it can work but I don't know if the behavior will ever
: be obvious for anything beyond the trivial.
The function reverses whatever its TEMP property's closure knows how
to reverse. It's up to the function to know what its side effects are
and arrange to undo them.
: FWIW my prompting to write File::chdir was a desire was for "local chdir".
: So if "temp chdir" can be made to work that would solve most of the problem.
:
: If nothing else perhaps chdir() should be eliminated and cwd() simply takes
: an argument to make it a getter/setter.
If you're going to throw away the verb then the noun might as well be
a variable. But I like verbs for their readability, even if the verb
is "push". Note that "push" could be made to work with "temp" as well:
temp push $CWD, "subdir" err fail "..."
This would automatically pop $CWD at the end of the dynamic scope.
: > However, I agree that it's nice to have an
: > easily interpolatable value. So I think I'd rather see $CWD always
: > return the current absolute path even after failure
:
: The problem there is it leaves $CWD without an error mechanism and thus
: becomes an unverifiable operation. You have to use chdir() if you want to
: error check and $CWD is reduced to a "scripting" feature.
That was my point. And if you look back at what you wrote, you just
called $CWD an "operation". It's not--it's a noun. I like nouns,
but I also like verbs, and unlike in Perl 5 we don't have to rely on
the magical side effects of certain mystical nouns to do localization
any more.
But I don't understand what you mean by a "scripting" feature, or
how getting reduced to one is antithetical to a blissful existence.
: It could throw an exception but then you have to wrap everything in a try
: block. Unless Perl 6 is going this route for I/O errors in general I'd
: rather not.
We're not advocating mandatory exceptions unless you've said "use Fatal",
but I am asking for some consideration of the fact that verbs are often
expected to fail while nouns generally are not. This stemming from the
basic linguistic fact that verbs tend to be active while nouns tend to
be passive.
Larry
