Joseph Ryan wrote:
> >That's the question of whether stringification will strictly be
> >serializing, or whether that will be a method call and stringification
> >should "look pretty" or "be useful". I prefer the latter.
>
> Same.
Can you define a good preferred "useful"? I find the current behavior
of references (stringify to a weird address thing) to be annoying;
people sometimes use it to test (for example) whether two references are
identical, but hopefully we'll be able to offer something better than that.
A core problem is that people tend to use stringification for at least
two distinct things: (1) actual, pretty input/output, and (2) random
debugging messages. For actual I/O, I'd like (for example) references
to be invisible (e.g. \%hash stringifies same as %hash), and things to
be as pretty as possible, without having to work for it. But for
debugging, I'd like _everything_ to stringify much like perl5's horrible
"HASH(05f3ed80)" cruft, so I can see exactly what's going on.
But the two uses are incompatible: by supporting one goal, we pretty
much trash the other. By supporting the "useful internal" stuff, we are
making it more difficult to use stringification for simple, common text
I/O purposes. By supporting the "pretty" stuff, we are making it more
difficult to print useful debugging messages.
This is an annoyance I've felt with most programming languages: there's
more than one "flavor" of number, so why isn't there more than one kind
of string? Why are we always stuck with one definition of "string" that
always works the same way, when clearly people use stringlike behaviors
for numerous different tasks?
<Thinking aloud> Can't there be more than one type of "stringification"?
For example, stringification into a C<Str> type would choose to print
prettyified output, while stringification into a C<DebugStr> type would
output in an ugly-but-useful way:
print "Your current configuration is:\n%Config"; # normal case
my str = "Hello, $personObj"; # obj stringifies to name
warn qd|Hash 'Config' -> %Config|; # quote-debugging?
my DebugStr = "Person is $personObj"; # can a literal "" know it's context?
Alternatively, there could perhaps be a marker such that prettyified is
the default, but you can still get 'internal' stringification:
print "Hello, $personObj"; # normal stringification
print "Person: *$personObj"; # 'internal' stringification
Or 'internal' stringification can be a method call upon the var:
print "Person: $personObj.debug";
Hmm. Haven't thought it entirely through, but do people understand my
frustration with having to choose between "pretty" and "rigorous"
stringification, when any given program typically needs both?
> >But Apoc 2 thought that <<qw stuff>> was spelled < qw stuff >. I
> >really don't know whether it should or not.
>
> Thats true; why exactly was <> abandoned in favor of <<>> in the first
> place?
Originally (A2) the perl5 I/O meaning of <thing> (iterate through lines
of input file, etc.) was going away, freeing up <> to be used for qw.
This was reversed in E2 or E3; as of the most recent discussions, it
looks like <thing> will morph into a generic iterator with a number of uses.
So <<qw stuff>> was chosen to not conflict with <stuff>.
MikeL
