Re: Per-object inheritance in core a red herring?
On Fri, Jun 29, 2001 at 04:42:57PM -0400, [EMAIL PROTECTED] wrote:
It's also not without its faults. Having every instance of a
class have different values of ref() could be obnoxious, for
example.
Why? You shouldn't be relying on an object's reference. ref $obj eq
'Some::Class' wrecks subclassing, $obj-isa('Some::Class') is the
right way.
If you're relying on an overload isa() method to determine if something
belongs to a given class you're going to run into problems. Several times
I've used UNIVERSAL::isa($obj, Some::Class) to determine if $obj is both
an object and belongs to the specified class.
I suppose you could modify UNIVERSAL::isa to forward the call on to the
class, but at that point the hack is no longer well-encapsulated.
No, that's a lousy rule of thumb. The tradeoffs must be considered.
Otherwise we'd have Forth. (Or Lisp, ca. 1960.)
What's the trade-off here? It works, its efficient, the hacks are
well encapsulated.
The reason the feature (object-level ISA) was suggested in the first place
was to solve the problem of multiple, pointless, only-there-to-set-@ISA,
classes to serve MI. How often is MI really used? Would this solution
greatly speed up MI? Would it greatly reduce the speed and memory
efficiency of the large body of OO code that doesn't use MI? These
questions really haven't been answered, nor do I think they really can be at
this point (at least, not the latter two).
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 328 (v2) Single quotes don't interpolate \' and \\
On Fri, Sep 29, 2000 at 09:20:23PM -, Perl6 RFC Librarian wrote: Although consensus so far is against the change, views were from Bexisting perl users [who do you expect as the majority on perl6 lists? :-)]. The change would penalise existing perl users, but benefit new perl users (and presumably people teaching perl). I'm not sure if this means you don't care about the opinions of existing Perl programmers or not, but perhaps you would like an opinion from a different direction. I hate the shell's single-quoting method. If I have anything with single quotes in it (usually Perl oneliners, but that's neither here nor there) I have to find some alternative. Usually I have to go back, change the quoting to "", and escape everything inside the single quotes. This is incredibly annoying. With Perl it could be marginally better, what with the q// construct, but it still means that when I have a single quote internally I have to go back and change my delimiter, and verify I'm not using that same delimiter in the string. Whew. Disallowing escapes in a single-quote string does not make easy things easier and hard things possible. The only thing it does is serve to make a shell programmer's introduction to Perl easier, maybe. Is this really a reason to take a feature away from the rest of us? Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 351 (v1) Beyond the amnesic eval
On Fri, Sep 29, 2000 at 09:47:00PM -, Perl6 RFC Librarian wrote:
Classic eval:
eval {}
eval ""
Unscoped eval
+eval {}
+eval ""
I like the general idea of this RFC, but the proposed syntax is less than
desirable. What happens with the following?
$result = 20+eval"$x $op $y";
Perhaps instead of +eval, consider unscoped_eval, or some such.
Or perhaps this should be generalized into a pragma for indicating the
current scope is actually the scope just above it. I believe this idea was
proposed and batted around when the lists were first started; I don't recall
what became of it.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: my and local
On Thu, Sep 28, 2000 at 10:18:34AM +0100, Tom Christiansen wrote: As we sneak under the wire here, I'm hoping someone has posted an RFC that alters the meaning of my/local. It's very hard to explain as is. my is fine, but local should be changed to something like "temporary" (yes, that is supposed to be annoying to type) or "dynamic". Someone has: RFC19 "Rename the Clocal operator" http://tmtowtdi.perl.org/rfc/19.pod Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 171 (v3) my Dog $spot should call a constructor implicitly
On Thu, Sep 28, 2000 at 12:25:32PM +0100, Tom Christiansen wrote: You also didn't mention that you would have broken the symmetry between my Dog $spot; our Dog $spot; No, I didn't mention our Dog $spot should be the same thing, but on an our variable. Or that constructors have no (and should have no) set name in Perl. What of TIEARRAY, TIEHASH, TIEHANDLE, etc.? What of the alternative for providing an author-specified implicit constructor name through a pragma? Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely
On Mon, Sep 25, 2000 at 02:17:38PM -0700, Nathan Wiger wrote:
import Foo;
You're beginning to blur your own fine line here. import is a class method
call using indirect object syntax.
But notice the disconnect here:
package Foo;
use base 'Bar';
Seems almost that:
package 'Foo';
use base 'Bar';
Would be more consistent.
Using 'Foo' with package implies $foo, or foo(), or "f" . "oo", or any
scalar, would work.
This whole idea reminds me of the quote:
A foolish consistency is the hobgoblin of little minds.
-- Ralph Waldo Emerson
Not to say you have a little mind, but is this a foolish consistency?
Most of Perl's bareword handling is what I mean, with the exception of class
method calls, which we already have a proposal for fixing. You are also
already proposing we keep certain exceptions to your 'no barewords' rule.
So what's left?
print STDERR "Foo";
We have a proposal to turn STDERR into $STDERR, and it looks likely it'll go
through.
$time = time;
print;
If use strict 'subs' is in effect you're guaranteed these are subroutine
calls, or compile-time errors. If it isn't you get a nice little warning.
Perhaps the stringification should be removed entirely, and the syntax
always be a subroutine call.
Class-foo()
shift-bar()
new Foo;
Class method calls, regardless of the existence of a subroutine in scope,
under the new proposal. I'm not sure of the last one, but it seems natural:
force the user to disambiguate with parens if they truly meant Foo() to be a
subroutine call.
stat-{'mode'}
No ambiguity here.
use Foo;
require Foo;
package Foo;
%foo = (bar = "baz");
All exceptions to the rule.
$foo{bar}
There's one you didn't mention. Currently it's unambiguous, you have to use
$foo{+bar} or $foo{bar()} to get a subroutine call.
Did I miss anything?
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely
On Mon, Sep 25, 2000 at 03:50:20PM -0700, Nathan Wiger wrote:
So I assume you're suggesting that this:
stat-{'mode'}
be a call to stat(), which returns a hashref, but this:
stat-mode
would be a call to the method mode() in the class 'stat'
That's not how I read RFC 244. If it is, I like it even worse.
I quote:
Currently,
foo-bar($baz)
can be parsed either as C'foo'-bar($baz), or as
Cfoo()-bar($baz) depending on how the symbol Cfoo was used on
other places. The proposal is to always choose the first meaning: make
C - autoquote the bareword on the left.
You expect a beginner or even intermediate user to wrap their heads around
that?
I don't see many beginners trying for such shortcuts. I've called methods
on shift, but I don't expect a beginner to try that, and by the time they
do, I expect them to know enough Perl to understand the source of their
errors. This behaviour should be documented. Enough code will be in place
to drive it home.
Auto-quoting - is a Bad Idea. Let's not forget there's plenty of ways
to disambiguate this already!
$stuff = stat::-mode; # class 'stat'
$stuff = stat()-mode; # function 'stat'
The point is not that it's easy to disambiguate, the point is it's easy for
the construct to be ambiguous. I'm willing to live with stat()-mode if it
means stat-mode always means "call the method mode in the class 'stat'".
Why should we make Perl any less flexible by default? I just don't get
it. I've personally never had any problems with this:
$q = CGI-new
Accidentally calling CGI()-new. Has anyone else really? Or is this a
theoretical concern?
This is not a theoretical concern. If someone, at some point, defines sub
CGI {} your constructor suddenly fails. If you're using something along the
lines of Animal::Bear-new(), and the author of Animal.pm defines a Bear()
method, your constructor suddenly fails. This is action at a distance.
It's a pain.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely
On Mon, Sep 25, 2000 at 04:50:32PM -0700, Nathan Wiger wrote:
Is just as much of a pain because of action-at-a-distance. Solving this
problem with highly-specific solutions gains us nothing but more
syntactic inconsistencies and ambiguities, like these:
stat-{'mode'}
stat-mode
working massively differently. That's confusing!! It is!!! Really.
Then say stat()-{'mode'} and stat::-mode, if it makes you feel better. Or
better yet, always say stat()-anything when you mean the function call.
Honestly, if you're using both a stat class and a stat function in your
code it's up to you to keep it straight; Perl should make the easy thing
(calling a class method, for certain) easy.
The solutions are:
use bareword 'literals';
# ... lots of intervening code ...
stat-mode; # call the mode method in the class 'stat'
stat-{'mode'}; # you can't dereference a scalar, silly
or
use bareword 'functions';
# ... lots of intervening code ...
stat-{'mode'}; # call stat(), access the mode key
stat-mode; # call stat(), die when it's discovered it isn't an object
or
stat-{'mode'}; # call stat(), access the mode key
stat-mode; # call the mode method in the class 'stat'
The last seems more DWIMish to me.
We need to step back and fix the *problem*: barewords vs. functions are
ambiguous. In *all* contexts. Always. You can screw yourself with any of
these equally:
$SIG{TERM} = IGNORE;# "IGNORE" or IGNORE()?
print output @stuff;# print(output(@stuff))
# or output-print(@stuff)?
$r = new CGI; # new(CGI) or CGI-new?
$q = CGI-new; # "CGI"-new or CGI()-new?
$name = first . middle; # "firstmiddle" or
# first() . middle()?
$total = number + 42; # number() + 42 or
# "number" + 42?
I only see two action-at-a-distance potentials in the above, the two class
method calls. I addressed everything else, I'm not going to repeat the
list.
The problem is this: barewords and functions are ambiguous. Always.
*ALL* contexts.
You keep uttering these absolutes as if the more times you utter them the
more true they'll get. From all of the examples shown the only ambiguity
I've seen is when it comes to class methods.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely
On Mon, Sep 25, 2000 at 05:49:21PM -0700, Nathan Wiger wrote:
Michael Fowler wrote:
Honestly, if you're using both a stat class and a stat function in your
code it's up to you to keep it straight
Exactly my point. So why is this
stat-mode
Any different? It's not.
Yes, it is, because you are not necessarily the only one who has control
over whether or not there is a stat function in the current namespace. Or,
on a more complex level, whether or not your parent class has subroutines by
the same name as you.
stat-{'mode'}; # call stat(), access the mode key
stat-mode; # call the mode method in the class 'stat'
Actually, under RFC244 stat-{'mode'} should be stat()-{'mode'}, so this
issue is moot, and that last example would have problems. You are forced to
disambiguate.
Try this code:
print header . "\n";
use CGI qw/:standard/;
print header . "\n";
So you're claiming that's not action at a distance? You're completely
wrong. The same exact mechanism causes 'Class' to become Class() -
modules exporting functions into your namespace.
I guess I will repeat myself, and I quote:
$time = time;
print;
If use strict 'subs' is in effect you're guaranteed these are subroutine
calls, or compile-time errors. If it isn't you get a nice little
warning. Perhaps the stringification should be removed entirely, and
the syntax always be a subroutine call.
Notice the last sentence.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 12 (v3) variable usage warnings
On Wed, Sep 20, 2000 at 07:45:16PM -, Perl6 RFC Librarian wrote: "VARIABLE used only once: possible typo" should be replaced with warnings on uses of uninitialized variables (including lexicals). $x = 3 I don't understand, who's to say you didn't misspell $x? If you're only using it once wouldn't that be likely? Who writes a program consisting of only assignments to variables that are never used, and expects not to see the "VARIABLE used only once: possible typo" warning? complains, but $x = 3; $x = 3 As it shouldn't; you've mentioned $x twice, which means you probably didn't misspell it. That your mentioning twice in this manner is silly is beyond perl's grasp. does not, nor does my $x = 3 I would say that this should complain just as $x = 3 would. Note that if you currently depend on lexical variables having undefined values, you would need to change Cmy $x to Cmy $x = undef. This is a good thing. Whoa, are you saying that saying 'my $x' no longer means $x has the value undef? What value does it have? How can this be a good thing? Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 12 (v3) variable usage warnings
On Wed, Sep 20, 2000 at 03:25:11PM -0700, Steve Fink wrote:
complains, but
$x = 3; $x = 3
As it shouldn't; you've mentioned $x twice, which means you probably didn't
misspell it. That your mentioning twice in this manner is silly is beyond
perl's grasp.
Actually, it isn't. I've often written $x = $x = 3 simply to avoid this
warning, because in the current implementation perl can't several of the
different ways of using a variable.
Which is silly, because you shouldn't have to say '$x = $x = 3' when you
mean '$x = 3'. Just because there's a real reason behind it doesn't make it
any less silly.
But I think you're missing the point. Why would you assign a value to a
variable, but then never use that variable's value? All typos would be
caught by the "initialized but never used" warning, as well as other
mistakes.
So, in the code:
$foobal = 3;
if (@ARGV) {
$foobar = @ARGV;
}
print $foobar;
Only warn me that $foobar is uninitialized? I always prefer it when the
actual source of my problem is pointed out, rather than its symptoms.
Whoa, are you saying that saying 'my $x' no longer means $x has the value
undef? What value does it have? How can this be a good thing?
No. No semantics change. This RFC is... what's the opposite of
far-reaching? It changes no semantics. It only adds warnings. 'my $x'
still means $x's value is undefined (but please do not say "the _value_
undef").
I'm saying the value undef now, because that's exactly what it is, now. I
have learned that 'my $foo' is an implicit 'my $foo = undef', for all
intents and purposes.
my $x;
...some code that might set $x to some value...
if (defined ($x)) { ... }
is bad, but
This is an idiom I use all the time, and I don't see anything wrong with it.
The value is undef, and I don't want to see this change at all.
my $x = undef; # or my $x; undef $x;
I just have to say, ick. 'my $x' is easy, 'my $x = undef' is slightly
annoying. 'my $x; undef $x;' is confusing; declare a variable, and then
immediately undefine it, so I can avoid uninitialized value warnings?
Blech. What of a list of declarations, 'my($foo, $bar, $blah)'? do I get
lots of warnings unless I assign undef to, or undef, all of those?
This is the same as in gcc; in gcc, the compiler remembers whether an
integer variable has been initialized, and complains when you use it. But
at runtime, that variable has some numeric value (a junk value, zero more
often than not.)
I never particularly liked this feature of C, that a variable had junk in it
naturally until you assigned something to it. I much prefer how Perl does
it; give it a sane value, but warn whenever that value is used unless it was
intentional (by using defined or conditionals).
Perl's runtime specifically tracks variables and expressions whose value
is undefined, and does it well enough that most people think of 'undef' as
being just another value.
It is just another value AFAIK, PL_sv_undef.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 12 (v3) variable usage warnings
On Wed, Sep 20, 2000 at 05:20:54PM -0700, Steve Fink wrote:
$foobal = 3;
if (@ARGV) {
$foobar = @ARGV;
}
print $foobar;
Only warn me that $foobar is uninitialized? I always prefer it when the
actual source of my problem is pointed out, rather than its symptoms.
It's exactly the same behavior as now, if you add in the "maybe it's a
typo?" guess. Which sounds fine to me.
Except for the line number reported, which is the important part.
Something that isn't defined() means that either nobody bothered to
assign a value to it, or somebody took away its value.
I think of undef as a value in and of itself, not simply a state of being.
A value that has magical properties, and that is recognized in various
places, but a value nonetheless. Perhaps I've been corrupted by the
implementation (or what I understand of it), but there it is.
With my style of programming, my($foo,$bar,$blah) would rarely trigger
warnings, because I would do something with those variables before using
them. I rarely use defined() to mean "if the control has happened to
take a route that never affected the values of this variable". In those
cases, I wouldn't mind using an explicit undef.
I would. I have not done it personally, but I do maintain code that has
something along the lines of:
my($foo, $bar, %baz, @qux, $quux, $blah ... ad nauseum);
This new warning would make life difficult for me.
It sounds like your style of programming is different. So you wouldn't
enable those warnings. And also that you find the existing warning
useful, which means the control over the warnings must be more
fine-grained than all or nothing. Sounds reasonable to me. And you might
want to temporarily turn on full warnings mode, ignore the spurious
messages, fix the bugs uncovered, and turn the warnings back off.
If your warning is optional, turned on by an explicit use warnings call, and
not included in its default set, I'm fine with it.
But do you like the feature of C where it warns you at compile time when
this is going to happen?
Yes, and Perl currently has the very same thing, except with the additional
warning when I use a variable that has not been declared. This being Perl,
it's natural; you cannot use a variable in C without declaring it, so the
issue never comes up.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 222 (v1) Interpolation of method calls
On Fri, Sep 15, 2000 at 10:58:26AM +0200, Bart Lateur wrote:
MJD has a "silly module" which can tie a hash to a function:
Interpolation.pm. I think I would like a special case, a specific hash
that is *always* tied to a function that returns the arguments. Make it,
for example, %$, %@ or %?. These are not in use now, are they?
print "You have to pay $?{money($amount)} dollars.";
I always thought MJD's module was neat, but never had a real desire for
interpolated function calls. If it was part of the core library I may be
inclined to use it more, but I doubt it.
Or maybe an alternative, using :
"foo foo(arg, arg, arg) bar"
"foo { foo(arg, arg, arg) } bar"
I suspect this has already been discussed and discarded at some point; I
sincerely doubt I'm the only one who came up with it.
Or maybe we need a more generic solution (as someone else suggested, I
forget who). Something that allows the arbitrary execution of code, much
like @{[ ]}, but cleaner. Unfortunately, I can't think of anything
suitable.
Whatever direction this discussion takes, I don't think it should impact the
interpolation of method calls. It'd be nice to find a clean and simple
syntax for calling functions within double-quoted strings, but it's already
clean and simple to call methods.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC - Interpolation of method calls
On Fri, Sep 15, 2000 at 07:24:39PM -0500, David L. Nicol wrote:
The only decision, then, is to decide which context to use; if it
deparses to concatenation then it seems logical to use scalar context.
This also makes sense in that you can force list context with @{[
$weather-temp ]} if you really wanted it.
$ perl -le 'sub w{wantarray?"WA":"WS"};print " attempt: ${\scalar(w)}"'
attempt: WS
Maybe we just need a shorter synonym for Cscalar?
Or DWIM "${\foo()}" to force scalar context. Everytime I come across that
construct I have to wonder why it's not called in scalar context. The '$'
would seem to imply it should.
Or cause the foo() method in "foo $foo-bar bar" to be called in scalar
context by default, obviating the need for a specific scalar call.
I'd actually like both solutions to be implemented.
What's even more confusing:
sub foo { wantarray ? "list" : "scalar" }
print scalar("${\foo()}") -- "list"
print scalar(${\foo()}) -- "list"
$foo = ${\foo()}; print $foo-- "list"
And yet:
sub foo { wantarray ? \"list" : \"scalar" }
print ${foo()} -- "scalar"
print ${ ("bar", foo()) } -- "scalar"
(These were all tested using 5.6.0.)
I have to assume \foo() is actually \(foo()) or some such. IMHO, this is
entirely non-intuitive. Can anyone enlighten me as to why this is as it is?
I believe there was a p5p discussion about this, but I dread delving into
the archives again..
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 226 (v2) Selective interpolation in single quotish context.
On Fri, Sep 15, 2000 at 11:25:31AM -0700, Steve Fink wrote:
I agree. I'd like q/.../ to stick as close to giving me ... as possible.
I can live with the current 'foo\\bar' having only one backslash in it,
but I'd rather not have to worry about anything else. I'd vote for
Glenn's allowing the disabling of interpolation in qq// and ""
instead.
Does it strike anyone else as odd that 'foo\\bar' eq 'foo\bar'?
Not at all. I can't count the number of times I have railed against bash
for deciding that you cannot escape ' inside ' (e.g. 'foo\'s bar'). Being
unable to escape \ would cause similar grief (e.g. 'foo bar\\').
This is incredibly annoying when doing Perl one-liners especially; one is
forced to use single quotes so that bash doesn't attempt to interpolate
variables itself. Unfortunately, one can't use single quotes internally
unless you say \047 or its equivalent (which I nearly always have to go look
up), or q{} if you're quoting something. q{} has saved my sanity more than
once.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC - Interpolation of method calls
This topic is actually covered, albeit far less in-depth and lumped with an
unrelated change, by Nathan Wiger's RFC 103, just in case you weren't aware.
On Thu, Sep 14, 2000 at 03:57:41AM -0400, Michael G Schwern wrote:
Methods will be run in scalar context. A method which returns a single scalar
is treated normally. If a list is returned, it should be treated same as
array interpolation. The list seperator will be applied. In effect, the
deparsing will really work out as follows:
print 'Today\'s weather will be '.join($", $weather-temp()).
' degrees and sunny.';
However if temp() calls wantarray(), the result will be FALSE (scalar).
Ok, this is very confusing. You're saying the method is called in scalar
context, but then proceed to call it in list context, meanwhile tricking it
into thinking it's scalar context. Interpolated method calls should behave
the same as every other method call, without extra magic.
The only decision, then, is to decide which context to use; if it deparses
to concatenation then it seems logical to use scalar context. This also
makes sense in that you can force list context with @{[ $weather-temp ]} if
you really wanted it.
=head2 Argument passing
Interpolation should also handle passing arguments to methods in a string:
print "Today's weather will be $weather-temp("F") degrees and sunny.";
This should deparse to:
print 'Today\'s weather will be '.$weather-temp("F").
' degrees and sunny.';
The arguments to the method are considered as normal expressions, thus:
print "There is $obj-foo(this = $yar, that = 2 + 2) in my head.";
deparses as:
print 'There is '.$obj-foo(this = $yar, that = 2 + 2). ' in my head.";
Now perl is parsing full statements within strings. I -really- don't like
this, not only because perl is now reaching into strings to parse yet more,
but also because it's already beginning to look very difficult for me,
personally, to parse. Not only that, it gives me the heeby-geebies (which
of course means you should all immediately agree with me :).
I'd say keep it simple, allow only simple, non-parenthetical method calls.
"foo $foo-bar bar" -- "foo " . $foo-bar . " bar"
"foo $foo-bar() bar" -- "foo " . $foo-bar . "() bar"
Granted, it may confuse the newbies, but I think it makes things much easier
on everyone.
Normally, whitespace is allowed between tokens of a method call.
$obj - bar ("this");
and
$obj-bar("this");
are equivalent. Whitespace between the object, '-', method name and opening
paren should be disallowed when interpolated. This will avoid many ambiguous
cases.
This is a good idea, and has precedence (as I just discovered answering
someone's question about it in #Perl as I was writing this email, weird..):
"$hash - {'foo'}" -- "HASH(0x8bbf0b8) - {k1}"
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC - Interpolation of method calls
On Thu, Sep 14, 2000 at 07:49:32AM -0700, Nathan Wiger wrote:
print 'Today\'s weather will be '.join($", $weather-temp()).
' degrees and sunny.';
However if temp() calls wantarray(), the result will be FALSE (scalar).
I think what he's trying to get at is that these should all work the
same:
print "Here's some @stuff";
print "Here's some $h-{stuff}";
print "Here's some $r-stuff";
That may be, but I don't think calling it in one context, accepting another,
and lying about it all is the right way to go. I think I'll let the author
try to explain what he had intended.
print 'There is '.$obj-foo(this = $yar, that = 2 + 2). ' in my head.";
Now perl is parsing full statements within strings.
This already happens with:
print "Here's some $h-{$stuff}";
print "Here's some $a-[$stuff + $MIN]";
So it's not that confusing, and quite consistent.
Well, I still find it confusing (most probably because of the length of the
examples), but it is indeed consistent. Stupid mistake on my part.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 222 (v1) Interpolation of method calls
On Thu, Sep 14, 2000 at 06:37:22PM -0500, David L. Nicol wrote:
A possibility that does not appear in RFC222.1 is to put tho whole
accessor expression inside curlies:
print "Today's weather will be ${weather-temp} degrees and sunny.";
which would follow the "You want something funny in your interpolated
scalar's name or reference, you put it in curlies" rule. Since the contents
of that expression is not strictly \w+ it does not get interpreted as
the symbol table lookup ${'weather-temp'}, so that is not a problem, nor
are the whitespace situations listed in the CAVEATS section.
Currently, ${weather-temp} means dereference the return value of the method
'temp' in the 'weather' class as a scalar reference (or a symbolic
reference, if it's not a scalar reference and you're not using strict). Do
you intend for this meaning to be taken away entirely, or to be
special-cased within interpolated strings? If either I would have to
heartily disagree with you; it's inconsistent, and while special cases can
be a good thing when it comes to DWIM, I think we should DWIM on the side of
interpolating method calls, rather than taking away existing syntax.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)
On Fri, Sep 08, 2000 at 04:57:46AM -, Perl6 RFC Librarian wrote:
=head3 Merge CTIESCALAR, CTIEHASH, and CTIEARRAY into CTIE
In practice, people rarely make a class that Cties multiple data types
through the same interface. The reason is that CSTORE, CFETCH,
CDESTROY, and other methods overlap. As such, it is more feasible to
create several different modules; witness CTie::Array, CTie::Scalar,
CApache::Session, and other modules.
I'm not so sure about this. As Schwern mentioned, it'd be nice to know what
exactly is being tied, and he suggested a first argument of the type. But
isn't this just moving the information from the subroutine name into @_?
I'd much rather Perl say "oh, you can't tie a hash, there's no TIEHASH"
than be forced to switch on the first argument and raise a fatal exception
if I can't support what's being tied.
Instead, this RFC proposes that Ctie's operation become much more
fundamental, simply translating functions via the existing indirect
object syntax:
tie Transaction %trans;# indirect object constructor
$trans{$var} = $value ;# $obj-STORE($var, $value);
lock $trans{$var}; # $obj-lock($var);
Ignoring for a moment the ambiguities inherent in indirect object syntax
(which we should all be aware of), what says $trans{$var} is not an object
in itself, on which we want to call the lock method?
=head3 Cuntie should take all references out of scope
When called, Cuntie currently suffers the somewhat nasty problem of
not being able to automatically destroy inner references. This means if
you've mixed OO and Ctied calls, you may not be able to destroy your
tied object as easily as you like. Cuntie should forceably destroy
hanging references. [2]
I would argue that this should be handled with weak references, and not
enforced by untie(). I don't necessarily want Perl deleting my object
behind my back because I untied a variable.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly
On Mon, Sep 04, 2000 at 10:25:37AM +0100, Piers Cawley wrote: Maybe a compromise along the lines of: my Dog $spot = LIST; # $spot = Dog-new(LIST) my Dog $patches; # $patches is undefined but we assert that # it'll be a Dog. (Whether you can do # $patches-new is left as an exercise) Where the first element of LIST is not a Dog. If you want to autocreate a null object then you can do Cmy Dog $spot = () I was trying to keep away from the $scalar = (LIST) construct calling a constructor with a list of arguments. It's very unintiutive for me. As for the latter, having on create an object and the other not seems inconsistent. It also precludes simple usage, as mentioned in the examples section: my int ($x, $y, $z); my array_ref @matrix; my int %counters; That's not polymorphism, that's inheritance. Ahh, of course, duh. Well, I don't know how you think this proposal breaks polymorphism, and at this point I don't particularly care. Given several different objects, if they all have the same method, calling the method on each will work just fine. I'm proposing an implicit constructor, not the breaking of OO. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly
On Sun, Sep 03, 2000 at 12:42:52PM +0200, Bart Lateur wrote: But now you're throwing away the kid with the bathwater. my Dog $spot; initially was syntax invented so that $spot was marked as only been ably to reference a Dog, with as a result that code internally could be optimized, by doing things at compile time why otherwise would need to be dealt with at runtime. (use fields, as the most notable example). Don't throw that away. Just to be clear, I'm not throwing it away. Nothing's preventing the compiler from still doing that optimization. I'm simply tacking on additional meaning, that it creates a Dog object out of $spot. It's been something of a struggle to word the RFC correctly so that it properly conveys that the old usage of my Dog $spot won't work as used currently, but the optimization can still be done. Does that make any sense? Your proposed isa(Dog) syntax is supposed to replace that syntax, while the old syntax would get new functionality. It doesn't look nice, for a start. The idea breaks the "if it does something else, give it a new name" rule. How about: my new Dog $spot; That's definitely an alternative. I don't particularly like it, but it's an alternative. That is, assuming we all (or at least, most of us) want an implicit construction mechanism. From the discussion, that doesn't seem to be the case. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly
On Fri, Sep 01, 2000 at 10:58:36AM -0800, Michael Fowler wrote: my $spot isa(Dog); This should be my $spot : isa(Dog); Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly
On Fri, Sep 01, 2000 at 12:35:24PM -0700, David E. Wheeler wrote:
Well then, that makes this example rather wasteful, doesn't it?
It wasn't an example of how my Dog $spot should be used. I was explaining
to Nate what his code was doing.
my Dog $spot;
if ($input eq 'Collie') {
$spot = Collie-new;
} elsif ($input eq 'Dalmation') {
$spot = Dalmation-new;
}
Becuase we're creating two objects when we really only want one.
Yes. That my Dog $spot should be either my $spot or my $spot : isa(Foo)
(which I just recently made up) in this case.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 171 (v1) my Dog $spot should call a constructor implicitly
On Tue, Aug 29, 2000 at 12:57:07PM -0700, Matt Youell wrote:
So perhaps sometimes in Perl we could say:
my Dog $spot = undef;# Automagically knows to be a Dog ref instead
of a Dog object because of the undef.
if ($age 12) {
$spot = new Doberman();
} else {
$spot = new Corgi();
}
That's a little too special-case and magical for my tastes. What if the
programmer really wants to call the constructor with an undef argument? Or
what if the programmer calls my Dog $spot = $foo, expecting $foo to be
defined, but it isn't? That would end up being a difficult to trace bug.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 171 (v1) my Dog $spot should call a constructor implicitly
On Tue, Aug 29, 2000 at 11:04:26PM -0400, Michael Maraist wrote: First greatly stylistic compatibilty. An inexperienced programmer would see: my Dog $spot = "Spot"; And become confused. It's totally unintuitive (at least so far as other mainstream OO languages go). It looks like Dog could be a type of String subclass. Granted, the my Dog $spot = "Spot" example is a little confusing. In this specific example it doesn't make much sense to assign a value in this way. Consider, however, types: my int $i = 4; my float $f = 8.5e10; possibly even (and I'm making syntax up here): my int ($x, $y, $z) = (4, 5, 6); This general syntax is not entirely unseen, consider C: int x = 4; int x = 4, y = 5, z = 6; or C++: string foo = "bar"; The latter being an overload of the assignment operator; any arbitrary value could be there, provided you have an overload that matches it. It's up to the author of the library (or module) to make it make sense. The next most important point is that, up until this point, there has been no enforcement of the constructor name (nor for the $self name). This obviously requires it. Now there have been numerous discussions about RFCs that required such standardization. Some stronger than others. I don't think that this alone is a strong enough case to break backward compatibility (with things like DBI-connect). The constructor name is only forced (if it's not author-controlled) when using the my Dog $spot syntax. my $spot = Dog-new() isn't going anywhere. As with the above, the problem you are trying to solve is long type-names (which is a bazzar thing to find in perl anyway). I just think that there are better ways of skinning that cat. Well, if it were only long type names I'm trying to solve, Doug MacEachern submitted a patch that provides for: my __PACKAGE__ $spot = Animal::Mammal::Canine-new(); to be the equivalent long version. (At least, that's what I think it's supposed to do.) I was going for more elegance and simplicity, especially in the case of specifying types. Perhaps you can suggest some alternatives? :) Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 177 (v1) A Natural Syntax Extension For Chained References
On Tue, Aug 29, 2000 at 07:27:15PM -0700, Peter Scott wrote:
$r-{{qw(a b c d e f g h)}}
$r-{a}-{b}-{c}-{d}-{e}-{f}-{g}-{h}
$r-{a}{b}{c}{d}{e}{f}{g}{h}
which is only one character longer than the proposal...
Except in the case where you don't have the list until run-time. I made a
class once that emulated the hierarchical structure of a filesystem using a
deep hash of hashes. It had an accessor something like:
$obj-file(qw(usr local bin gpg));
or
$obj-file("/usr/local/bin/gpg"); # which would get split
(I'm paraphrasing and changing syntax, because I don't actually recall the
actual syntax I came up with.)
The accessor would traverse down the internal hash of hashes to retrieve the
information about /usr/local/bin/gpg. With current syntax this is rather
awkward, resulting in code something along the lines of:
my $cur = $hoh;
foreach my $file (@_) {
if (exists $$cur{$file}) {
$cur = $$cur{$file};
} else {
# error
}
}
So the syntax would be useful; I'm not sure how useful, such deeply nested
hashes requiring run-time key lookup like that are a rarity. The array
syntax would also be useful in multi-dimensional arrays.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 111 (v1) Whitespace and Here Docs
On Thu, Aug 24, 2000 at 05:41:00PM -0600, Tom Christiansen wrote: But you don't need that when you can and possibly should just write this: print "EOF" =~ /^\s*\| ?(.*\n)/g; | Attention criminal slacker, we have yet | to receive payment for our legal services. | | Love and kisses | EOF This works for print, but not for other functions where the string is in a single argument, rather than a list. printf( 'EOF' =~ s/^\s*\| ?//g, '[EMAIL PROTECTED]', "Michael Fowler", '400' ); | To: %s | | Hello %s, your payment of $%.2f is late. Please pay now. | | Love and Kisses EOF Though, granted, the example is a little contrived. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 111 (v1) Whitespace and Here Docs
On Thu, Aug 24, 2000 at 05:24:14PM -0700, Peter Scott wrote: At 05:41 PM 8/24/00 -0600, Tom Christiansen wrote: But you don't need that when you can and possibly should just write this: print "EOF" =~ /^\s*\| ?(.*\n)/g; Others may be focussing on the problem of stripping off leading white space from the here doc contents, but I don't so much care about that because I think the Ram recipes are fine; I'm more concerned about being able to indent the terminator and not have to count spaces in the . I was sorta going under the assumption that would cause leading and trailing whitespace to be ignored (not stripped) when looking for the end-of-here-doc indicator. Because whitespace is ignored, I was then proposing some new syntax for stripping whatever one likes from the contents of the here-doc. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 111 (v1) Whitespace and Here Docs
On Thu, Aug 24, 2000 at 05:26:36PM -0600, Tom Christiansen wrote:
I thought this problem would've been neatly solved by my proposed:
print "FOO" =~ s/^ {8}//;
Attention criminal slacker, we have yet
to receive payment for our legal services.
Love and kisses
FOO
The result of substituting the leading 8 blanks (which might be tabs!)
from the very front just once is probably 1, which isn't a very interesting
thing to print. :-(
Oh, well, there should have been a /g there. And the regex may not work for
everyone (it would work wonderfully for me). If you like:
print "EOF" =~ s/^\s*\| ?//g;
| Attention criminal slacker, we have yet
| to receive payment for our legal services.
|
| Love and kisses
|
EOF
Basically, it's shorthand for the current syntax:
$message = "EOF" =~ s/^\s*\| ?//g;
| Attention criminal slacker, we have yet
| to receive payment for our legal services.
|
| Love and kisses
|
EOF
print $message;
But any inconsistencies or errors in my examples should not detract from the
general idea.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 111 (v1) Whitespace and Here Docs
On Wed, Aug 16, 2000 at 03:05:23PM -, Perl6 RFC Librarian wrote: With a here doc print ZZZ; the ZZZ has to be at the start of a line and the text of the here doc, is processed verbatum. This results in Here Docs that either stick out in the code, or result in unwanted leading whitespace. There are several FAQs that relate to this problem. This proposal tidies this up. [snip] This will ignore all leading white space on each line until the end terminator is found. It effectively does s/^\s*// before processing each following line. It also ignores whitespace (but not the line termination) after the terminator. So what's insufficient about: print "EOF"; Stuff More stuff Even more stuff EOF Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 105 (v1) Downgrade or remove In string @ must be \@ error
On Tue, Aug 15, 2000 at 04:09:51PM -0400, Ted Ashton wrote: Better yet, DWIM. If I write print "[EMAIL PROTECTED]"; and no array @southern exists, I probably mean I want it to print [EMAIL PROTECTED] I'd say, if the variable exists, interpolate it. If not, print it as it stands. Some time ago, this is how it was done, to stay backwards compatible. In recent versions (the farthest I can tell is 5.004) it became a fatal error. I don't think we should go backwards. If someone uses @, they mean array. A warning should be emitted, but it should print a blank string. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 109 (v1) Less line noise - let's get rid of @%
On Tue, Aug 15, 2000 at 05:10:34PM -0400, Dan Sugalski wrote: The ultimate target of a program's source code is the *programmer*. Programmers, being people (well, more or less... :), work best with symbols and rich context. Stripping contextual clues out of code does the programmer a disservice. We're at the point where we don't have to cater to the limitations of the computer hardware. That means we'll be better off if we cater to the limitations (and strengths!) of people's wetware. Let's not move backwards and force people to work like machines. Instead, lets force machines to work like us. Exactly! I would also like to remind everyone that, despite abandoning backwards compatibility with programs, we should by no means abandon backwards compatibility with Perl programmers. Removing the special symbols would be quite a shock to most Perl programmers (including me), and we don't want to alienate those who know Perl. I say these things for purely selfish reasons; I like Perl, and want it to look much the same as it does now. Perl is a wonderful language. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 83 (v1) Make constants look like variables
On Fri, Aug 11, 2000 at 06:36:44PM +0100, Andy Wardley wrote: How about any variable created in UPPER case is a constant? This involves Perl dictating style to the user. Very un-Perllike, IMHO. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 90 (v1) Builtins: zip() and unzip()
On Sat, Aug 12, 2000 at 07:22:01AM +1000, Damian Conway wrote: dwim @results, dwim $stuff, @args, %hey; Can you say 'Lisp'? Lithp Michael (who couldn't resist) -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
the currying operator
I like the idea of currying, it seems powerful and Perlish in many ways. However, I don't like the currying operator chosen, because of it's ugliness (IMHO), and its potential for ambiguity (human, not necessarily parser). So, here is my proposal to change the operator. from to --- ^_^^ ^2, ^3^^2, ^^3 ^named^^named To me, it stands out better, and is less likely to cause the programmer looking at it to scratch his head and try to figure out if it's an xor or a curry. I did it myself several times, and I consider myself at least a competent programmer. I know I'm coming into this late, I apologize. I did not follow much of the discussion. I've tried to catch up on the arguments via the archive as best I could, but I may have missed something. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: the currying operator
On Fri, Aug 11, 2000 at 02:52:32AM -0700, Nathan Wiger wrote: Jeremy's got a great explanation of this, which I'll paraphrase, but the discussion went through lots of iterations. Think of the ^ as a carat or thumbtack, holding the place for later variables. Yea, I ran across the description, and it was well thought-out and describes the decision rather well. However, I am reminded of my first look at the currying syntax. Had I read Jeremy's justification before seeing the example I may have been able to parse it easier, but as it was I had to get past the ^_ and ambiguities with ^. I suspect this is how most people will get their first taste of currying (was that a pun? :). I suppose I can get over it and live with the operators as they are, and so can anyone else, but I would much rather love it than simply live with it. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 48 (v2) Objects should have builtin stringifying
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 CSTRING method is called
automatically. If no CSTRING method is defined, then it should simply
return undef (instead of printing out the ref/class info).
I'm not so sure about returning undef here. Why not fall back to the
default behaviour of Perl 5 without overload q{""} magic? As in, return the
stringified reference.
If people want to see the ref info, they can still type:
print $object;
since this is not a string context. However,
As Bart Lateur (who I've been meaning to thank for pointing it out, thanks!)
pointed out, the object there -is- stringified; use overload q{""} magic is
called.
So, some method should be provided to avoid the stringification, akin to
overload::StrVal(). Perhaps overload::StrVal is sufficient.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: Safer OO inheritance
On Tue, Aug 08, 2000 at 06:22:03AM +1000, Damian Conway wrote: I'm more in favor of a mechanism that makes it easy to build field names from the package name, for those rare cases where you want scoped fields. [snip] See the Tie::Securehash module for a variation on this theme. Also note that I will be proposing something similar in my general revamp of Perl OO (RFCs galore, probably next week). Which is exactly what I thought of when I saw the original message. If tying is sped up, Tie::SecureHash could become far more viable for production code. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: Safer OO inheritance
On Mon, Aug 07, 2000 at 01:57:14PM +0200, Jean-Louis Leroy wrote:
package Foo;
sub new
{
bless { "${CURRENT_PACKAGE}name" = 'Simpson' ...
}
...where $CURRENT_PACKAGE is a special variable automatically set
to...guess what? ;-)
Is $CURRENT_PACKAGE any different, value-wise, than __PACKAGE__? Is there a
reason to prefer it? I understand it can be interpolated, making it easier
to use within a string, but weigh that against adding yet another special
variable, for a value that's already available otherwise.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
type-checking [Was: What is Perl?]
On Tue, Aug 01, 2000 at 10:09:32AM -0700, Tony Payne wrote:
The ability to have strong-typing (I don't trust Junior Engineers to get it
right and I don't have time to check every line of code they write)
Several people have suggested strong typing as a feature, and have been shot
down one by one. However, I think it can be done without forcing it on
everyone.
In fact, it can be done with Perl 5, as various people have pointed out,
through tying. Unfortunately, accessing and manipulating tied variables is
incredibly slow. Improving their speed is obviously an implementation
detail (not belonging to a -language list), but would improve the language
by allowing the addition of extra syntax, like type checking, without
requiring it to be in core (that is, perl core, not the core distribution).
So, I envision syntax like this:
use typing; # place your fingers on the home row..
integer $foo, $bar, $blah;
string($baz, $qux) = ("bazarific", "quxaroni");
# and even..
my integer $quux = 4;
Except for the last part, the above syntax is doable in Perl 5. At least, I
assume the string example is; I couldn't quite get lvalue subs to work as I
expected when testing things.
With tying, however, exceptions (That's not an integer! *croak*) are made at
run-time, rather than compile-time (as would be more useful). So you have
to test all code paths if you are to use this as any sort of internal sanity
checking; I assume most everyone does this, but it would be useful for it to
be a compile-time check, so that perl -c would catch all of your errors.
This could possibly be accomplished by allowing arguments to the pragma, or
variable initialization:
use typing qw(very-strict);
my integer $foo : very-strict = 4;
Which would enforce that you can only assign integer constants to $foo
(which are seen at compile-time), or other similarly declared integers (or
possibly promoted floats, chars, etc. if you wanted to get C-like). This,
then, could allow you to do checking at compile-time.
Which then raises a few more problems (whew): how do you coax user input
(which is an SV) into a value $foo can accept with very-strict on?; what
happens when an external function (say, from a module) is being very-strict,
but is passed arguments from code that doesn't do type checking?
Now, once you have that, you could then extend the syntax (provided we have
a way of doing tie-like functions (where the first argument is any data
type) in user-space):
integer @ints = (1 .. 20);
Which is what someone out there was suggesting; this would give you an array
optimized to hold only integers, rather than SVs.
So, strong typing is doable, and not burdensome to those who don't want to
use it (which includes me). You can even get some efficiency gains from it.
This is not necessarily an endorsement for type checking, but I see more
than a few people asking for it, and if it can be done without severely
impacting those who don't want it, there's little reason to deny them (that
I can see).
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: type-checking [Was: What is Perl?]
On Tue, Aug 01, 2000 at 05:31:56PM -0600, Tom Christiansen wrote: Several people have suggested strong typing as a feature, and have been shot down one by one. However, I think it can be done without forcing it on everyone. Can it? Are you prepared to make everyone declare the full, formal, and fancy types for the return values of all their functions? No, this was intended to be a suggestion to provide a pragma or hooks (all of which are nearly doable in Perl 5) for type checking. This moves the onus of setting up a proper type-checking environment onto the shoulders of developers who wish to have type checking. I raised the question about how to handle it when a subroutine doing type checking is called by code that isn't; the question can go the other way. For the first situation (a subroutine doing type-checking is called by code that is not) there will probably have to be a runtime penalty to coerce the parameters into type-checked values. For the second situation (code doing type checking calls a subroutine that is not) would be much like the previous situation (runtime penalty, coercion of return values into type-checked values). There is also a management problem: suddenly some of your values aren't being type-checked. The only solutions I can think of offhand are: take your lumps and accept that some things won't be checked; write wrapper functions that -do- check; have some sort of mechanism that's basically a language- or pragma-level construct that does the wrapping for you: typing_proto funcname = [qw(ARRAY INTEGER HASHREF)], [qw(FLOAT)]; I'm not sure how well this fits into my original musings on doing certain things at compile-time to provide for compile-time warnings. It probably doesn't. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
