[RFC] StringHandle interface

[NotFound]

There some points in the StringHandle pmc that needs clarification:

- Read/Write mode: Must it works the same as FileHandle? Several tests use read methods in a StringHanlde opened for writing. IMO will be better to have methods to get/set the string content, use the get_string/set_string/native vtable functions, or both, and have the read methods throw exceptions when not opened for read.

- Mode when reopened without second argument: must use the flags used on the previous open, or use the 'r' default? Several tests assume the second, but works only because of the first issue.

[NotFound]

In today parrotsketch has been decided that the StringHandle PMC is not stable, so expect changes in it and his tests without notice. Please comment on this ticket ASAP if anyone is using it other than for testing purposes.

[fperrad]

The StringHandle PMC is used by Lua, in standard library function io.tmpfile (file src/lib/luaio.pir).

But this use could be easily removed.

[NotFound]

I'll take a look at it before changing anything.

[jkeenan]

'StringHandle' is found fairly widely in the distribution:

$ ack -l StringHandle | sort
compilers/opsc/src/Ops/Emitter.pm
config_lib.pir
include/parrot/core_pmcs.h
lib/Parrot/Config/Generated.pm
lib/Parrot/PMC.pm
runtime/parrot/library/TAP/Parser.pir
src/core_pmcs.c
src/io/api.c
src/pmc/stringhandle.pmc
t/compilers/opsc/07-emitter.t
t/dynoplibs/io.t
t/library/archive_tar.t
t/pmc/stringhandle.t

So it looks like we're not contemplating removing it anytime soon?

Okay to close this ticket?

Thank you very much.

kid51

[whiteknight]

This ticket is about the programmatic interface used by StringHandle, and how it should behave in certain situations. We don't plan to remove StringHandle, but we do want to make sure it behaves in a way that's consistent with our other IO types.