Re: RFC 260 (v1) More modules
On 19 Sep 2000 19:41:20 -, Perl6 RFC Librarian wrote: >Perl should come distributed with more modules. I know of people/sites where installing the whole lot of Perl just to run a tiny script, is not acceptable as an option. Not everyone is a developer. -- Bart.
Re: RFC 228 (v1) Add memoize into the standard library
On Fri, 15 Sep 2000 08:28:30 -0700 (PDT), Dave Storrs wrote:
> Personally, I like the way it works at the moment; all the subs
>that you want to memoize are up at the top, where they are easy to see.
You have a point.
What I don't like is how the basic module syntax pretty much requires
the function name as a *string* in order to install itself underneath
it. That has every appearance of a hack. (symbolic references)
Memoizing using function references would look a bit better.
My preferred (most compatible) syntax:
use Memoize foo;
sub foo {
...
}
It should complain, at compile ime, if the sub doesn't exist.
Implementation is a problem, because at the time the import sub is
called, the function hasn't been compiled yet.
Current syntax and behaviour:
use Memoize;
memoize "foo";
foo(1);
foo(2);
foo(3);
foo(2);
foo(1);
foo(4);
sub foo {
my $s = shift;
print "Argument = $s\n";
$s * $s
}
-->
Argument = 1
Argument = 2
Argument = 3
Argument = 4
It does what it should do, but as I said, it looks like a hack.
Replace the second line (the memoize statement) with:
memoize foo;
Unquoted string "foo" may clash with future reserved word at test.pl
line 3.
Argument = 1
Argument = 2
Argument = 3
Argument = 4
It still works, but (a), it still treats "foo" as a string, and (b) it
complains (or worse).
Replace that line with:
memoize \&foo;
-->
Argument = 1
Argument = 2
Argument = 3
Argument = 2
Argument = 1
Argument = 4
No complaint, but it doesn't work either.
--
Bart.
Re: RFC 228 (v1) Add memoize into the standard library
On 15 Sep 2000 02:09:23 -, Perl6 RFC Librarian wrote:
>A version of Memoize.pm should be added into the Perl6 standard
>library, and it should be added as a pragmatic module (i.e. memoize.pm).
Is that it?
I would rather have a flag when generating the sub, er, what's that
syntax again, ":something"?
sub foo :memoize {
...
}
This would take out the dirty work of marking a sub as memoized.
Currently, the syntax is:
memoize('foo');
sub foo {
...
}
Blech!
--
Bart.
Re: How to implement both object->method and module::function interface?
On Wed, 9 Aug 2000 14:26:25 +0100, Graham Barr wrote:
>That is being considered. IF that does become part of the language I could
>see subs do something like
>
> if (defined $SELF) {
>called as a method
> }
> else {
>called as a sub
> }
That was my idea. The current unfixable bug I showed in CGI.pm would
easily be fixed. However, Hildo's argument WRT inheritance makes me less
convinced that it is the ultimate ideal.
--
Bart.
Re: How to implement both object->method and module::function interface?
On Wed, 09 Aug 2000 13:58:34 +0100, Hildo Biersma wrote:
>Yikes. Class method calls should perform inheritance, subroutine calls
>should not.
I agree with that.
>Altering the language to make the two look the same is a bad
>idea, because it breaks, fatally, as soon as the class supports more
>than one object at a time.
Then, the alternative method would be NOT to use the word "sub" any more
in order to make a method.
method param {
... # this is a method, including inheritance
}
sub param {
... # this is an ordinary function; no inheritance
}
Both could well coexist withing the same module; but they can't both be
CODE refs.
--
Bart.
Re: How to implement both object->method and module::function interface?
On Wed, 09 Aug 2000 11:41:20 +0100, Hildo Biersma wrote: >Could we agree on the idea that CGI.pm should be split up? No. I could agree that CGI->somemethod(@args); would do exactly the same as CGI::somemethod(@args); i.e. no difference between function calls and class methods, unless the method explicitely wants to know. Why make module authors' life even more miserable? Passing the class/object in a magic variable, e.g. $SELF, instead of in the arguments list, is one way. -- Bart.
Re: How to implement both object->method and module::function interfa ce?
On Tue, 8 Aug 2000 14:22:20 -0500 , Garrett Goebel wrote:
>What's the conventional wisdom on creating a module that supports both an OO
>and non-OO interface? Are there any CORE or CPAN modules to serve as a
>textbook, or is the anwser "Don't do that"?
>
>I've got some code that checks the first parameter passed to see if it is a
>reference, assumes any reference is an object reference... and then proceeds
>accordingly. -It feels pretty sloppy, but it works.
Gee, I wonder what this is doing on the Perl6 mailing lists. But, maybe
there are some lessons to be learned, so...
My idea is: "Don't do it". Let me point to just one example: CGI.pm.
Probably one of the most used modules, I might add. Open the source, and
scroll down till you find the definition for self_or_default, around
line 317 ($VERSION = 2.56). Oh hell, here it is:
sub self_or_default {
return @_ if defined($_[0]) && (!ref($_[0])) &&
($_[0] eq 'CGI');
unless (defined($_[0]) &&
(ref($_[0]) eq 'CGI' || UNIVERSAL::isa($_[0],'CGI'))
# slightly optimized for common case
) {
$Q = $CGI::DefaultClass->new unless defined($Q);
unshift(@_,$Q);
}
return @_;
}
Excuse me for the rewrapping. This sub is called at the start of every
single method, I think. It serves to distinguish between a plain sub
call, and a class or method call. If it's a method call, the name of the
"default class" is prepended to the arguments list.
This is a bug waiting to happen. Suppose you call it as a function, but
with a literal string:
$x = param('x');# Will work
$cgi = param('CGI');# Oops! Major goof here!
It will barf on the latter, because the sub "self_or_default" will think
it is called as a class method, but it isn't.
Lesson to be learned: this is a bug caused by poor design. Perhaps, a
special global variable -- local'ized, of course -- e.g. $SELF, ought to
have been set before the sub is called, to either the object (object
method) or class name (class method); or undef(), if called as a regular
function. The object/class should not have been unshifted unto @_.
Let's do better with Perl6.
p.s. Gee, if Perl6 is going to be so radically different than Perl5,
perhaps we need a new pragma:
use perl6;
or, in contrast:
use perl5;
which could turn on/off the backward compatibility mode.
--
Bart.
Re: Define consistent and standard
On Sun, 6 Aug 2000 01:13:22 +1000, [EMAIL PROTECTED] wrote:
>* Variables are things are nouns. Give them noun names.
> $name, $total, $input
>* Plural variables should have plural names
> @employees, @items, %contact_details
Hmmm...
>* Hash names should be written so that looking up an element reads clearly:
> $email_address{Skud} reads as "the email address of Skud"
>* Hashes with scalars as values should have singular names:
> my $address = $email_address{Skud};
>* Hashes with arrayrefs or hashrefs as values should have plural names:
> my @addresses = @{$email_addresses{Skud}};
I can relate to that.
But those two groups of rules contradict each other. Or, do yo want
$email_address{Skud} to be an element of the hash %email_addresses?
I've used both @item and @items as names for arrays. It depends on
whether I always use the data as a whole (@items), or mostly accessing
individual items, as in $item[3]. $items[3] does not look too well.
Yes, I'm being inconsistent, I know.
p.s.
> o While short identifiers like $gotit are probably ok,
> use underscores to separate words. It is generally
> easier to read $var_names_like_this than
> $VarNamesLikeThis, especially for non-native speakers
> of English.
Pooh.
But I do like the irony that the latter, $VarNamesLikeThis, is sometimes
called "Camel case": lots of lumps.
--
Bart.
