Re: RFC on Coexistance and simulaneous use of multiple module version s?
On Fri, 26 Jan 2001 16:37:23 -0500, Michael G Schwern [EMAIL PROTECTED] said: from what I remember we discussed an idea to allow people and organizations to produce their own list of approved modules. This is already possible with the CPAN::Site module. For example, if Oracle had their own QA people approve a set of modules and versions allowed for use in their company. These lists would be archived and made available just like CPAN is now. A subclass of the CPAN shell could be built allowing the user to specify which organizations they trust and it would only pull modules from there. This description goes a bit beyond CPAN::Site's abilities. This isn't *quite* what most people are thinking of, and it in no way addresses the problem of having multiple versions of the same module installed on a given machine, but it does allow people to pick and choose between implementations without fragmenting CPAN. Larry mumbled something like "implements" and "interface". So to say package Net::FTP::Foo implements Net::FTP; But I don't think, anybody wrote an RFC about the plan. -- andreas
Re: RFC on Coexistance and simulaneous use of multiple module version s?
[EMAIL PROTECTED] (Andreas J. Koenig) writes: On Fri, 26 Jan 2001 16:37:23 -0500, Michael G Schwern [EMAIL PROTECTED] said: from what I remember we discussed an idea to allow people and organizations to produce their own list of approved modules. This is already possible with the CPAN::Site module. For example, if Oracle had their own QA people approve a set of modules and versions allowed for use in their company. These lists would be archived and made available just like CPAN is now. A subclass of the CPAN shell could be built allowing the user to specify which organizations they trust and it would only pull modules from there. This description goes a bit beyond CPAN::Site's abilities. This isn't *quite* what most people are thinking of, and it in no way addresses the problem of having multiple versions of the same module installed on a given machine, but it does allow people to pick and choose between implementations without fragmenting CPAN. Larry mumbled something like "implements" and "interface". So to say package Net::FTP::Foo implements Net::FTP; But I don't think, anybody wrote an RFC about the plan. I did. Or something like it. And I've got a couple of modules on CPAN (that I really must document better) that kind of work already: package ShoppingBasket; use ex::interface qw/add_entry total_price delete_entry .../ 1; package Vendor::ShoppingBasket use ex::implements ShoppingBasket ... Which does nice compile time tricks to ensure that everything in the interface has been implemented. It's 5.6.0 only, and it currently tries to do too much (must cut it down), but I've found it surprisingly useful. Of course, the likes of CPAN takes no notice of it, and unless we start having some kind of module registry it's going to be hard to do: use ShoppingBasket; and have that import the local implementation of same... -- Piers
RFC195: Do not remove 'chop' PLEASE!
Hi,
I read RFC195 suggesting to drop 'chop' and go with 'chomp'.
What does 'chop' have anything to do with 'chomp'?
I'm totally oppose to that. Consider:
my $s;
map { /\S/ $s .= "$_ " } split(/\s+/,@_);
chop($s);
return $s;
Thanks,
Marc K.
Re: RFC on Coexistance and simulaneous use of multiple module version s?
Larry mumbled something like "implements" and "interface". So to say package Net::FTP::Foo implements Net::FTP; But I don't think, anybody wrote an RFC about the plan. I did. Or something like it. And I've got a couple of modules on CPAN (that I really must document better) that kind of work already: package ShoppingBasket; use ex::interface qw/add_entry total_price delete_entry .../ Interfaces are tricky. One must assume a common agreed-upon vocabulary or ontology. What does 'add_entry' mean, really and exactly? What arguments does it take? What arguments could it take? What does it return? Does it have non-local effects? -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC195: Do not remove 'chop' PLEASE!
On Sat, Jan 27, 2001 at 03:42:43PM -0700, root wrote:
I read RFC195 suggesting to drop 'chop' and go with 'chomp'.
What does 'chop' have anything to do with 'chomp'?
chop() and chomp() are very often confused due to their similar names,
similar functionality and the fact that chop() did chomp()'s job
(poorly) prior to perl5. Nowdays, chop() is very often used where
they really ment chomp().
Actually, the docs are somewhat to blame for this. perlfunc is loaded
with chop misuses. Will fix.
The complex nature of the complete chop() is unfortunate, it makes it
very difficult to reimplement and prototype. The basic version,
however, isn't hard:
sub chop (;\$) {
my($var) = @_ ? $_[0] : $_;
return substr($var, -1, 1, '');
}
Once you start getting into chopping lists and hashes, it becomes
impossible to prototype.
PS I just ran exactly into your example the other day dealing with
Text::Wrap guts.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
BOFH excuse #69:
knot in cables caused data stream to become twisted and kinked
Re: RFC on Coexistance and simulaneous use of multiple module version s?
Jarkko Hietaniemi [EMAIL PROTECTED] writes: Larry mumbled something like "implements" and "interface". So to say package Net::FTP::Foo implements Net::FTP; But I don't think, anybody wrote an RFC about the plan. I did. Or something like it. And I've got a couple of modules on CPAN (that I really must document better) that kind of work already: package ShoppingBasket; use ex::interface qw/add_entry total_price delete_entry .../ Interfaces are tricky. One must assume a common agreed-upon vocabulary or ontology. What does 'add_entry' mean, really and exactly? What arguments does it take? What arguments could it take? What does it return? Does it have non-local effects? Indeed. But Perl (at present) doesn't allow us to specify that kind of thing at the language level. The job of specifying said stuff is left to the documentation of the interface. More enforceable detail would be nice, but Perl's OO dispatch doesn't work like that. -- Piers
Re: RFC195: Do not remove 'chop' PLEASE!
On Sat, Jan 27, 2001 at 05:13:23PM -0500, Michael G Schwern wrote:
On Sat, Jan 27, 2001 at 03:42:43PM -0700, root wrote:
I read RFC195 suggesting to drop 'chop' and go with 'chomp'.
What does 'chop' have anything to do with 'chomp'?
chop() and chomp() are very often confused due to their similar names,
similar functionality and the fact that chop() did chomp()'s job
(poorly) prior to perl5. Nowdays, chop() is very often used where
they really ment chomp().
Actually, the docs are somewhat to blame for this. perlfunc is loaded
with chop misuses. Will fix.
The complex nature of the complete chop() is unfortunate, it makes it
very difficult to reimplement and prototype. The basic version,
however, isn't hard:
sub chop (;\$) {
my($var) = @_ ? $_[0] : $_;
return substr($var, -1, 1, '');
}
That doesn't modify its arguments (nor does it modify $_).
Once you start getting into chopping lists and hashes, it becomes
impossible to prototype.
This one not only modifies its arguments (or $_ when called without),
it also has the right prototype and works on lists:
sub chop (@) {
my $__;
map {$__ = substr $_ = -1, 1, ""} @_ ? @_ : $_;
$__;
}
Aliasing is a cute thing.
Abigail
Re: JWZ on s/Java/Perl/
I like the final point: Stay tuned, I'm sure I'll have found something new to hate by tomorrow. (Well, that's how this document originally ended. But it's not true, because I'm back to hacking in C, since it's the still only way to ship portable programs.) -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: JWZ on s/Java/Perl/
J. David Blackstone wrote: And in related news, it's a total pain that one can't iterate over the contents of an array without knowing intimate details about its contents: you have to know whether it's byte[], or int[], or Object[]. That's one nice thing about Perl; you can foreach over an array of all sorts of different things. In fact, being able to just have an array of all sorts of different things is something Perl still has over Java, C, and the like. It's not that big a deal. An array in Perl is like an array of Object in Java, or an array of void* in C. Like jwz said, if only they had done TRT and made intrinsics inherit (or appear to) from Object, it wouldn't be an issue in Java either. -- John Porter So take a pointed stick and touch Piggy's eyes He's gonna turn and leave you a big surprise
Re: JWZ on s/Java/Perl/
J. David Blackstone wrote: That's one nice thing about Perl; you can foreach over an array of all sorts of different things. In fact, being able to just have an array of all sorts of different things is something Perl still has over Java, C, and the like. It's not that big a deal. An array in Perl is like an array of Object in Java, or an array of void* in C. Well, not exactly like it. I try to avoid arrays of void* like the plague. :) But yes, you're right, it is _possible_ to get that effect. Like jwz said, if only they had done TRT and made intrinsics inherit (or appear to) from Object, it wouldn't be an issue in Java either. Yeah, that was one of my disappointments when I finally made the Java plunge last month. I kind of expected integers to be objects in what I had heard was the "perfect, pure" OO language. jdb
Re: RFC195: Do not remove 'chop' PLEASE!
On Sun, Jan 28, 2001 at 01:26:09AM +0100, [EMAIL PROTECTED] wrote:
On Sat, Jan 27, 2001 at 05:13:23PM -0500, Michael G Schwern wrote:
This one not only modifies its arguments (or $_ when called without),
it also has the right prototype and works on lists:
sub chop (@) {
my $__;
map {$__ = substr $_ = -1, 1, ""} @_ ? @_ : $_;
$__;
}
Aliasing is a cute thing.
I keep forgetting you can modify @_ in place. However, the prototype
on chop is beyond Perl's system. 5.6 reports it as undef, but 5.7.0
says @. Odd. 5.7.0 also adds the additional complexity of dealing
with hashes. Cchop(%hash) is supposed to work... and it does (on
your routine). How does that work? I'd expect %hash to be fed to the
subroutine as a list.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Paste is a waste if you're chaste,
but in this case dump a load
of goo and poo by the case in your face,
and place in your jawls like a juicy chaw,
but don't spit that shit and enjoy it all.
-- Ubergirl's beau
