Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
> Access details like this are largely independent of the logical
> manipulations made with pathnames. I can claim that there is
> "/foo/bar/zap.txt" and I can say that file directory part is
> "/foo/bar", but whether such an entity really exists, is
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
JH> I agree with Dan: people do seem to get into "have to" mode awfully
JH> soon and easily. The proposed framework is supposed to make it easy
JH> to handle file names and make Perl internals (well, not internal-
JH> internals, but the
> "JV" == Johan Vromans <[EMAIL PROTECTED]> writes:
JV> @parts = qw(sy $ foo bar 262);
JV> Now, create a file in the same directory with the same type, and name
JV> blech. Any idea?
I don't like this but how about
$resource = File::Generic "."
$resource->name = "
This all seems like a lot of work for (what I would consider to be) the
common, default case - wanting to open a file native to my OS, on a
filesystem seen by my OS. Or am I clue-lossy again?
--
Bryan C. Warnock
([EMAIL PROTECTED])
On Sun, Aug 13, 2000 at 01:19:03PM +0200, Johan Vromans wrote:
> Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>
> > Access details like this are largely independent of the logical
> > manipulations made with pathnames. I can claim that there is
> > "/foo/bar/zap.txt" and I can say that file dir
On Sun, Aug 13, 2000 at 07:54:34AM -0400, Chaim Frenkel wrote:
> > "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>
> JH> I agree with Dan: people do seem to get into "have to" mode awfully
> JH> soon and easily. The proposed framework is supposed to make it easy
> JH> to handle file
On Sun, Aug 13, 2000 at 09:40:07AM -0400, Bryan C. Warnock wrote:
> This all seems like a lot of work for (what I would consider to be) the
Read carefully the subject: *internal* representation. If you are
opening a file with open() or sysopen(), you supply a string with your
native FS semantics
Dan Sugalski wrote:
> Do we want to allow a variable to have multiple types of magic on it
> simultaneously?
Absolutely. It's a design requirement.
Fortunately with vtbls it's easy -- we just use mix-ins. Mix-ins are
partial implementations of a type that are designed to be merged into
a full im
Dan Sugalski writes:
: I'm not sure the vtable's the place for this sort of thing. (Plus then we
: start getting a zillion alternate functions--we'd have taint/notaint and
: thread/nothread right now for four, add another and that brings us to
: eight, then sixteen, then...) Besides, generally
Larry Wall <[EMAIL PROTECTED]> writes:
>Nick Ing-Simmons writes:
>: Chaim Frenkel <[EMAIL PROTECTED]> writes:
>: >Hmm, will vtbl get rid of all the magic hacks?
>:
>: The "mg.c" 'magic hacks' are in essence applying vtable semantics (they
>: are even called vtables in the sources) to a subset of
Dan Sugalski <[EMAIL PROTECTED]> writes:
>At 03:11 PM 8/12/00 -0700, Larry Wall wrote:
>>Nick Ing-Simmons writes:
>>: Chaim Frenkel <[EMAIL PROTECTED]> writes:
>>: >Hmm, will vtbl get rid of all the magic hacks?
>>:
>>: The "mg.c" 'magic hacks' are in essence applying vtable semantics (they
>>: ar
On Sun, Aug 13, 2000 at 01:22:30PM -0400, Chaim Frenkel wrote:
> > "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>
> JH> On Sun, Aug 13, 2000 at 09:40:07AM -0400, Bryan C. Warnock wrote:
> >> This all seems like a lot of work for (what I would consider to be) the
>
> JH> Read careful
On Sun, Aug 13, 2000 at 01:22:30PM -0400, Chaim Frenkel wrote:
> > "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>
> JH> On Sun, Aug 13, 2000 at 09:40:07AM -0400, Bryan C. Warnock wrote:
> >> This all seems like a lot of work for (what I would consider to be) the
>
> JH> Read careful
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>> Please explain why internally it needs to be represented as anything
>> other than what the user passed in.
JH> A flat string is a pain to handle because then you have to know
JH> in which platform it was originally created: what se
> And how do we make it easy to pass in a name to open?
In an email I sent to Jarkko off-list, I suggested this:
If we embedded full URI support into Perl, then people could write
portable scripts using URIs, or non-portable ones using native syntax.
*Internally*, both could be converted into so
On Sun, Aug 13, 2000 at 02:14:24PM -0400, Chaim Frenkel wrote:
> > "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>
> >> Please explain why internally it needs to be represented as anything
> >> other than what the user passed in.
>
> JH> A flat string is a pain to handle because the
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
JH> On Sun, Aug 13, 2000 at 09:40:07AM -0400, Bryan C. Warnock wrote:
>> This all seems like a lot of work for (what I would consider to be) the
JH> Read carefully the subject: *internal* representation. If you are
JH> opening a file w
> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes:
NW> Many others have begged :-) for URI support in open(), so it'll be in
NW> there. This seems like the easiest thing todo. No reason to reinvent the
NW> wheel, URIs are a well-established platform-independent naming scheme.
I'm not sure th
Bart Lateur <[EMAIL PROTECTED]> writes:
>On Wed, 09 Aug 2000 12:46:32 -0400, Dan Sugalski wrote:
>
>>> > @foo = @bar * @baz;
>
>>Given that the default action of the multiply routine for an array in
>>non-scalar context would be to die, allowing user-overrides of the
>>functions would probably
19 matches
Mail list logo
