John Porter <[EMAIL PROTECTED]> writes:
> Michael Fowler wrote:
> >
> > I think a stringified reference is worth seeing, moreso than a simple undef,
> > for debugging purposes if nothing else.
>
> I personally would like to have the stringification of refs be a
> symmetric operation, i.e. such
On Wed, Aug 09, 2000 at 08:37:35AM -0700, Nathan Wiger wrote:
> > I think a stringified reference is worth seeing, moreso than a simple undef,
> > for debugging purposes if nothing else.
>
> Debugging is great, but I don't think this is the way to do it. The
> reason is some objects might have a
> I think a stringified reference is worth seeing, moreso than a simple undef,
> for debugging purposes if nothing else.
Debugging is great, but I don't think this is the way to do it. The
reason is some objects might have a STRING method while others don't, so
you'll only get partial access to s
Hildo Biersma wrote:
>
> Bit dangerous there - the string-to-ref operator is left out for a
> purpose.
> - Would you really want the ref-counting system / the GC system to
> scan strings?
> - Would like like the effects of pointer arithmetic that
> the ref-tostring, edit-string, string-to-
John Porter wrote:
>
> Michael Fowler wrote:
> >
> > I think a stringified reference is worth seeing, moreso than a simple undef,
> > for debugging purposes if nothing else.
>
> I personally would like to have the stringification of refs be a
> symmetric operation, i.e. such a string should dwim
At 09:13 AM 8/9/00 -0400, John Porter wrote:
>Michael Fowler wrote:
> >
> > I think a stringified reference is worth seeing, moreso than a simple
> undef,
> > for debugging purposes if nothing else.
>
>I personally would like to have the stringification of refs be a
>symmetric operation,
That le
Michael Fowler wrote:
>
> I think a stringified reference is worth seeing, moreso than a simple undef,
> for debugging purposes if nothing else.
I personally would like to have the stringification of refs be a
symmetric operation, i.e. such a string should dwim in a ref context:
$r = bl
On Tue, Aug 08, 2000 at 07:01:29PM -0700, Nathan Wiger wrote:
> > On Tue, Aug 08, 2000 at 02:18:07PM -, Perl6 RFC Librarian wrote:
> > > Hooks will have to be put in Perl's string context so that if something
> > > is an object, then that object's C method is called
> > > automatically. If no
On Tue, 8 Aug 2000, Nathan Wiger wrote:
> However, as you point out, there's no easy way to get the HASH(addr)
> part. If this RFC is accepted, we might need a special function for that
> (but I say stick it in Data::Dumper).
Please don't worry about this. It's diving too deeply into what at thi
> On Tue, Aug 08, 2000 at 02:18:07PM -, Perl6 RFC Librarian wrote:
> > Hooks will have to be put in Perl's string context so that if something
> > is an object, then that object's C method is called
> > automatically. If no C method is defined, then it should simply
> > return undef (instead o
Jonathan Scott Duff wrote:
>
> And what about user-defined contexts? (my Dog $spot = some_func();)
> I think a context coercion operator would do just fine.
Oh, I agree entirely! But the intrinsic contexts should have concise
operators (e.g. scalar()).
--
John Porter
On Tue, Aug 08, 2000 at 05:15:24PM -0400, John Porter wrote:
> Jonathan Scott Duff wrote:
> >
> > If we had a context coercion operator that was the opposite of want()
> > we could do something like this:
> >
> > print context '*STRING', $val; # long-hand for print $val
> > print contex
Jonathan Scott Duff wrote:
>
> If we had a context coercion operator that was the opposite of want()
> we could do something like this:
>
> print context '*STRING', $val; # long-hand for print $val
> print context '*SCALAR', $val; # we're not in a string context
> print conte
On Tue, Aug 08, 2000 at 12:17:12PM -0800, Michael Fowler wrote:
> So, some method should be provided to avoid the stringification, akin to
> overload::StrVal(). Perhaps overload::StrVal is sufficient.
If we had a context coercion operator that was the opposite of want()
we could do something lik
On Tue, Aug 08, 2000 at 02:18:07PM -, Perl6 RFC Librarian wrote:
> Hooks will have to be put in Perl's string context so that if something
> is an object, then that object's C method is called
> automatically. If no C method is defined, then it should simply
> return undef (instead of printing
Dan Sugalski writes:
> Is this an update to the original RFC 48 with a new title? Or is it a new
> RFC mis-numbered?
Actually, it's an update to 49 with a slightly different title, so the
answer to both of your questions is "yes". The 48/49 confusion has
been cleared up in the archive.
Nat
At 02:18 PM 8/8/00 +, Perl6 RFC Librarian wrote:
>This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
>=head1 TITLE
>
>Objects should have builtin stringifying STRING method
>
>=head1 VERSION
>
>Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
>Date: 06 Aug 2000
> I am intrigued by the idea of a "scalar" context, and
> a "string" context though.
A string context is a special type of scalar. This distinction already
exists in Perl:
$one = $two; # scalar (not string)
print "$one";# string (and scalar)
-Nate
> In a scalar context, it could produce a date object always:
>
>$date = date;
>
> However, when you went to do anything with it in a string context, it
> would call the appropriate method:
>
>print "$date"; # calls $date->STRING, which in this case would
> # prin
19 matches
Mail list logo
