RE: Stringification of references and objects.
Joseph F. Ryan:
# Why? Isn't the pretty form more generally useful?
#
#
# I don't think so; I'd think it to be annoying to have type
# more code in order to specify a more cocise form; if I need
# to dump a structure, I'd prefer to do it manually.
I think it's useful to be able to say @array.str() and $arrayref.str()
and get the same result. And since we already know what @array.str will
do (essentially what @array does in Perl 5), that suggests that
$arrayref.str() will do the same.
# method str() {
# #Unnamed invocant means you need $_, right?
# return $_.class() ~ ($_.id());
# }
#
# (where id() returns a uniquely identifying integer, usually the
# address).
#
#
# Objects aren't references anymore, are they? So I don't
# think it is apporpriate for an object to stringify with its id.
To tell you the truth, I don't consider arrayrefs references anymore.
They're just Array objects that don't happen to be in @whatever symbols.
I don't know if this is the official view, but that fits my brain
better.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible.
--Ayn Rand, explaining how today's philosophies came to be
Re: Stringification of references and objects.
Brent Dax wrote To tell you the truth, I don't consider arrayrefs references anymore. They're just Array objects that don't happen to be in @whatever symbols. I don't know if this is the official view, but that fits my brain better. So you're saying that classes should stringify to a pretty-print of their public members?
Re: Stringification of references and objects.
On Friday, December 6, 2002, at 04:28 AM, Joseph F. Ryan wrote: Brent Dax wrote To tell you the truth, I don't consider arrayrefs references anymore. They're just Array objects that don't happen to be in @whatever symbols. I don't know if this is the official view, but that fits my brain better. So you're saying that classes should stringify to a pretty-print of their public members? How about something like what Ruby's irb does? % irb irb(main):001:0 class Foo irb(main):002:1def initialize irb(main):003:2 @a, @b, @c = 1, 2, 3 irb(main):004:2end irb(main):005:1 end nil irb(main):006:0 Foo.new #Foo:0x2767a4 @c=3, @b=2, @a=1 irb(main):007:0
RE: Stringification of references and objects.
Joseph F. Ryan:
# Brent Dax wrote
#
# To tell you the truth, I don't consider arrayrefs references
# anymore.
# They're just Array objects that don't happen to be in @whatever
# symbols. I don't know if this is the official view, but that fits my
# brain better.
#
#
# So you're saying that classes should stringify to a
# pretty-print of their public members?
No, because that wouldn't reveal enough for an equality check. At the
same time, however, exposing private members would be wrong, especially
since editing the string and creating a new instance from it would allow
the user to manipulate private members.
What I'm saying is that .str and .identity (for lack of a better name)
are identical in Object, but classes should feel free to override .str
if they have a better WTDI. The built-in classes (Array, Hash, etc.)
should override .str to yield their members in some format (probably
influenced by properties).
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible.
--Ayn Rand, explaining how today's philosophies came to be
Re: Stringification of references and objects.
On Friday, December 6, 2002, at 01:28 AM, Joseph F. Ryan wrote: Array(0x1245AB) Personally, I like this format. It's succinct, informative, and tells you enough to do identity testing. I like it too, but I thought everyone else hated it :) I think people like it fine, but many people don't want it to be the default stringification. Like I said in an earlier thread, the problem is that there's stringification for output purposes and stringification for debugging purposes, but we have to chose one or the other to be the default. I'd rather the debugging one _not_ be the default, personally, because I imagine the other usage is more common. An obvious counterproposal would be to say that references are invisible to stringification (e.g. it stringifies to whatever its contents stringify to). This would seem to be in keeping with the the spirit of arrayref/array transparentness, etc. So you're saying that classes should stringify to a pretty-print of their public members? No, the AS_STRING (or str(), or whatever) is definitely the way to go. We pretty much _have_ to do it via a method. Brent Dax wrote: What I'm saying is that .str and .identity (for lack of a better name) are identical in Object, but classes should feel free to override .str if they have a better WTDI. The built-in classes (Array, Hash, etc.) should override .str to yield their members in some format (probably influenced by properties). I like this a lot, personally. MikeL
Re: Stringification of references and objects.
On Fri, Dec 06, 2002 at 10:40:18AM -0500, Dan Sugalski wrote:
: If an aggregate and a reference to an aggregate are going to behave
: the same, which is what Larry's indicated in the past, then
: stringifying a reference should be the same as stringifying its
: referent.
This is a bit of an oversimplification. $foo and @foo do not always
behave the same, even if $foo and @foo refer to the same array object.
In particular, $foo doesn't behave like @foo in a list context.
Scalars must continue to behave like scalars in list context, even
if they're internally composite. As in Perl 5, if you say
for $foo {...}
the sub only gets one argument, the array ref, but if you say
for @foo {...}
or
for @$foo {...}
you get all of the elements.
But it's probably fair to say that $foo and @foo always behave
identically in a scalar context.
We may, in fact, have to deprecate the term list context and replace
it with something like flattening context, since we can have lists
of scalars that are in some sense in a list context but that aren't
in a flattening context:
my ($a,@b,%c) := (@a,$b,%c);
But flattening is a lousy word. It's really more of a variadic
context, but that's no improvement.
At the moment I can't think of anything better than splat context...
Larry
Re: Stringification of references and objects.
Michael Lazzaro [EMAIL PROTECTED] writes: On Friday, December 6, 2002, at 01:28 AM, Joseph F. Ryan wrote: Array(0x1245AB) Personally, I like this format. It's succinct, informative, and tells you enough to do identity testing. I like it too, but I thought everyone else hated it :) I think people like it fine, but many people don't want it to be the default stringification. Like I said in an earlier thread, the problem is that there's stringification for output purposes and stringification for debugging purposes, but we have to chose one or the other to be the default. I'd rather the debugging one _not_ be the default, personally, because I imagine the other usage is more common. Well, personally I think you're very wrong. Kent Beck is good on this in 'Smalltalk Best Practice Patterns': The two audiences for strings generated by objects, you and your client are often in conflict. You want all the internal, structural details of your object laid out in one place so you don't have to go searching layers and layers of objects to find what you want. Your client assumes the object is working correctly and just wants to see externally relevant aspects of the object in the string. He notes that VisualWorks Smalltalk makes the distinction between 'displayString', for the user oriented stringification and 'printString', for the programmer oriented. Personally I reckon that having the the default behaviour be the 'debugging' string makes too from the point of view of separation of concerns; generally you want to separate formatting from the objects themselves. Also, the debugging approach makes sense from the point of view of a 'composite' object. One can imagine cases where a contained object makes incorrect assumptions about how it is being displayed, which could cause problems for the implementation of the container's as_string method; instead of simply doing: join \n\t .members (say), you could find yourself adding class based overrides for different sorts of member objects and it could all get ugly quickly. An obvious counterproposal would be to say that references are invisible to stringification (e.g. it stringifies to whatever its contents stringify to). This would seem to be in keeping with the the spirit of arrayref/array transparentness, etc. Personally I'm not keen on this idea. The distinction between the thing itself and a pointer to the thing is an important distinction for the programmer to be aware of. -- Piers It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite. -- Jane Austen?
Re: Stringification of references and objects.
This is a bit of an oversimplification. $foo and @foo do not always behave the same, even if $foo and @foo refer to the same array object. In particular, $foo doesn't behave like @foo in a list context. Scalars must continue to behave like scalars in list context, even if they're internally composite. Am I the only one here who thinks Perl 6's rules for arrays/lists/refs are getting way too complicated? This is getting even worse than C's confusion of them. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Stringification of references and objects.
On Friday, December 6, 2002, at 01:08 PM, Piers Cawley wrote:
He notes that VisualWorks Smalltalk makes the distinction between
'displayString', for the user oriented stringification and
'printString', for the programmer oriented.
One could imagine a scenario in which a user could accomplish an
unlimited number of styles of stringification by creating multiple
subclasses of CStr, one per desired style:
class FormalStr is Str;
class InformalStr is Str;
class PersonName {
...
method FormalStr { $.hon $.first $.middleInitial\. $.last }
method InformalStr { $.nick || $.first }
}
my PersonName $name = .new(...);
my FormalStr $s = $name;# Dr. William P. Smith
my InformalStr $s = $name;# Bill
Whether that is good, bad, or indifferent I leave to the OO Police.
But the same approach could be used for Str and DebugStr, etc. It just
depends on what audience we want Perl6 str's to be geared for.
(Ignoring the various context/coercion issues raised by the above.)
MikeL
Re: Stringification of references and objects.
On 12/6/02 4:41 PM, Michael Lazzaro wrote: my PersonName $name = .new(...); my FormalStr $s = $name;# Dr. William P. Smith my InformalStr $s = $name;# Bill Whether that is good, bad, or indifferent I leave to the OO Police. I'm not even deputized, but I call foul: excessive use of subclassing ;) Even in Perl 5 code, I end up having multiple stringification methods for things like error messages. But I simply use different method names for each (e.g. error() and public_error()), and don't bother with overloading at all. I think the desire to have stringification DWIM is now bordering on RMMP (read my mind, please :) Yes, there will probably be many WTDI in Perl 6, but I doubt any will end up beating the simplicity and clarity of named methods. Standardizing these methods names in an effort to help out debuggers seems reasonable, but I wouldn't go much further than that. In fact, I'd go so far as to say that the default stringification of most objects should probably still be something like FOO(0x1234), since I frequently use those strings to find out if two things are pointing to the same object. At the very least, some sort of similar unique identifier should be accessible to any stringification method writer... -John
Stringification of references and objects.
A big issue that still remains with literals is the stringification of
objects and references. In an effort to get the behaviors hammered
down, here are a few ideas:
First off, references:
By default, references should not stringify to anything pretty, they
should stringifiy to something useful for debugging. Heck, even perl5
style should be fine. Not only is this handy, but also prevents
problems with circular referencing data structures, huge data
structures, etc. However, all built-in types should have a .repr()
method, which should provide primitive Data::Dumper-ish output
So:
$var = [1,2,3];
print $var;
print \n;
print $($var.repr);
Might print something like:
[REF_TO_ARRAY_AT: '0x1245AB']
[
'1',
'2',
'3'
]
Next, objects:
Objects should have an AS_STRING method inherited from UNIVERSAL
defined as follows:
method AS_STRING() {
return [CLASS_INSTANCE_OF: ' ~ $self.CLASS() ~ '];
}
The AS_STRING method is implicitly called when an object is
interpolated within a string. The AS_STRING method can be
overloaded within the class if the class's author wants nicer
(classier;) output.
so:
class Normal {}
class Special {
method AS_STRING() {
return qq['one','two',three']
}
}
my Normal $obj1;
my Special $obj2;
print $obj1;
print \n;
print $obj2;
Should print:
[CLASS_INSTANCE_OF: 'Normal']
'one','two',three'
RE: Stringification of references and objects.
Joseph F. Ryan:
# By default, references should not stringify to anything
# pretty, they should stringifiy to something useful for
# debugging. Heck, even perl5 style should be fine. Not only
Why? Isn't the pretty form more generally useful?
# is this handy, but also prevents problems with circular
# referencing data structures, huge data structures, etc.
# However, all built-in types should have a .repr() method,
# which should provide primitive Data::Dumper-ish output
#
# So:
#
#$var = [1,2,3];
# print $var;
# print \n;
# print $($var.repr);
#
# Might print something like:
#
# [REF_TO_ARRAY_AT: '0x1245AB']
What's wrong with a Perl 5-esque format for the debugging version?
Array(0x1245AB)
Personally, I like this format. It's succinct, informative, and tells
you enough to do identity testing.
# Next, objects:
#
# Objects should have an AS_STRING method inherited from
# UNIVERSAL defined as follows:
I'd prefer if we drop the capitals. str() ought to work fine, IMHO.
# method AS_STRING() {
# return [CLASS_INSTANCE_OF: ' ~ $self.CLASS() ~ '];
# }
Once again, what's wrong with:
method str() {
#Unnamed invocant means you need $_, right?
return $_.class() ~ ($_.id());
}
(where id() returns a uniquely identifying integer, usually the
address).
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible.
--Ayn Rand, explaining how today's philosophies came to be
Re: Stringification of references and objects.
Brent Dax wrote:
Joseph F. Ryan:
# By default, references should not stringify to anything
# pretty, they should stringifiy to something useful for
# debugging. Heck, even perl5 style should be fine. Not only
Why? Isn't the pretty form more generally useful?
I don't think so; I'd think it to be annoying to have type more code
in order to specify a more cocise form; if I need to dump a structure,
I'd prefer to do it manually.
# is this handy, but also prevents problems with circular
# referencing data structures, huge data structures, etc.
# However, all built-in types should have a .repr() method,
# which should provide primitive Data::Dumper-ish output
#
# So:
#
#$var = [1,2,3];
# print $var;
# print \n;
# print $($var.repr);
#
# Might print something like:
#
# [REF_TO_ARRAY_AT: '0x1245AB']
What's wrong with a Perl 5-esque format for the debugging version?
Array(0x1245AB)
Personally, I like this format. It's succinct, informative, and tells
you enough to do identity testing.
I like it too, but I thought everyone else hated it :)
# Next, objects:
#
# Objects should have an AS_STRING method inherited from
# UNIVERSAL defined as follows:
I'd prefer if we drop the capitals. str() ought to work fine, IMHO.
# method AS_STRING() {
# return [CLASS_INSTANCE_OF: ' ~ $self.CLASS() ~ '];
# }
Once again, what's wrong with:
method str() {
#Unnamed invocant means you need $_, right?
return $_.class() ~ ($_.id());
}
(where id() returns a uniquely identifying integer, usually the
address).
Objects aren't references anymore, are they? So I don't think it is
apporpriate for an object to stringify with its id.
Joseph F. Ryan
[EMAIL PROTECTED]
