Re: New module: Type::Tie::Full
On Fri, Apr 30, 2021 at 4:23 AM Asher Gordon wrote:
> Hello,
>
> I'm writing a new module that exports a similar interface to Type::Tie,
> but performs a type check on the entire variable each time it is
> changed. Obviously, this is much more expensive, but it can be useful
> for types like Types::Standard::Dict in cases where speed is not very
> important.
>
> In case you're not familiar with Type::Tie, here's a brief summary:
> Type::Tie exports a single function, ttie(), which ties variables to
> types. For example, after
>
> use Type::Tie;
> use Types::Standard qw(Num);
>
> ttie my $num, Num;
>
> setting $num to anything but a number will die. And
>
> ttie my @num_list, Num;
>
> only allows numbers in @num_list. So
>
> push @num_list, "foo";
>
> will die.
>
> Type::Tie::Full (the working name for my module) is similar, except that
> the entire variable (as a reference) is passed to the type checker. The
> sole exception to this is tying scalars--in this case, the referenced
> scalar will be passed to the type checker rather than the reference
> itself.
>
> For example, this works correctly:
>
> use Type::Tie::Full;
> use Types::Standard qw(Dict Optional Str Num);
>
> ttie my %dict, Dict[string => Str, number => Optional[Num]],
> string => 'foo';
>
> $dict{string} = 'bar';# ok
> $dict{number} = 42; # ok
> $dict{nonexistent} = 'foo';# dies
> $dict{number} = 'foo';# dies
>
> delete $dict{string}; # dies ('string' is not optional)
> delete $dict{number}; # ok ('number' is optional)
>
> Currently, only one layer of tying is performed, which means things like
> the following don't work how I would like them to:
>
> use Type::Tie::Full;
> use Types::Standard qw(HashRef Num);
>
> ttie my $hashref, HashRef[Num], {};
>
> $hashref = { foo => 'bar' }; # dies ('bar' is not a number)
> $hashref->{foo} = 'bar'; # doesn't die, but probably should
>
> I intend to implement this using deep tying, but it doesn't work for
> now.
>
> My question is, does the name make sense for this module? I figure since
> it performs a full check on the variable every time it is changed (as
> opposed to a check on just the added elements), then it makes sense to
> call it that. Would you agree?
>
Any namespace under Type::Tie you like seems appropriate to me. One
suggestion I have is Type::Tie::Aggregate, since it performs a type check
on the aggregate variables rather than the elements.
-Dan
Re: New module: Text::Wrap::OO
Hi Joey, Joey Kelly writes: > You ought to put it in git, no doubt (and everything else you write). For sure. I'll release the git repository at the same time as the module on CPAN. When I said "eventually," I think I accidentally implied "in a long time," which is not what I meant. Asher -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me sprea= d! GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Re: New module: Text::Wrap::OO
Hi Dan, Thanks for the quick reply! Dan Book writes: > It's a fine list for that purpose. You may also seek feedback on > https://perldoc.perl.org/perlcommunity#IRC or > https://www.reddit.com/r/perl/. Ok, thanks. > The name and design seem fine to me. Just beware providing so many > options for doing the same thing that you'll have to support them all > (common mistake of the "DWIM era" of CPAN), sometimes it is better to > keep things simple and only add alternative options once they are > useful. I didn't think about that. Perhaps I should only keep the object interface then. After all, people can write their own subroutines if they really need to. Thanks for the advice. > Also make sure you are aware that CPAN distributions must be packaged > a specific way. The first few sections of > https://metacpan.org/pod/Dist::Zilla::Starter go over this and some > modern options for authoring (you don't have to use Dist::Zilla unless > it fits your approach). http://tynovsky.github.io/cpan-tutorials/ also > lays out a quick guide to authoring with Minilla. Actually, I'm already using Dist::Zilla for my module. I also wrote a plugin bundle for Dist::Zilla and Pod::Weaver (Dist::Zilla::PluginBundle::Author::ASDAGO and Pod::Weaver::PluginBundle::Author::ASDAGO). I haven't released them yet, but I will at the same time as my module. Thanks, Asher -- Early to rise, early to bed, makes a man healthy, wealthy and dead. -- Terry Pratchett, "The Light Fantastic" GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Re: New module: Text::Wrap::OO
On April 6, 2021 11:15:45 AM MST, Asher Gordon wrote:
>Hi everyone,
>
>I have just written my first Perl module (that I'm going to release).
>It
>is an object oriented interface to Text::Wrap. My question is, what do
>you think of the name? Is it a good name, descriptive enough? And do
>you
>have any other advice for releasing my first module?
>
>I don't currently have it released anywhere (I'll eventually have the
>git repository on sv.nongnu.org), and I'm not sure if an attached
>tarball would be appreciated (I can attach it if requested), but here's
>the SYNOPSIS so you can get an idea of what it does and how it works:
>
>SYNOPSIS
> Object oriented interface
> use Text::Wrap::OO;
>
> my $wrapper = Text::Wrap::OO->new(init_tab => "\t");
> $wrapper->columns(70);
> my $wrapped = $wrapper->wrap($text);
>
> Static method interface
> use Text::Wrap::OO;
>
> my $wrapped = Text::Wrap::OO->wrap(
> {
> init_tab=> "\t",
> columns => 70,
> }, $text,
> );
>
> Exported interface
> use Text::Wrap::OO 'wrap',
> wrap => { columns => 70, -as => 'wrap70' };
>
> my $wrapped = wrap {
> init_tab=> "\t",
> columns => 60,
> }, $text;
>
> my $wrapped_70 = wrap70 {
> huge => 'overflow',
> }, $text;
>
>Thanks in advance,
>Asher
>
>P.S. https://pause.perl.org/pause/query?ACTION=pause_namingmodules
>seems
>to indicate that this is a good list for this type of question. Sorry
>if
>I was mistaken.
You ought to put it in git, no doubt (and everything else you write).
--Joey Kelly
--
Sent from my Android phone, while driving.
Re: New module: Text::Wrap::OO
On Tue, Apr 6, 2021 at 2:19 PM Asher Gordon wrote:
> Hi everyone,
>
> I have just written my first Perl module (that I'm going to release). It
> is an object oriented interface to Text::Wrap. My question is, what do
> you think of the name? Is it a good name, descriptive enough? And do you
> have any other advice for releasing my first module?
>
> I don't currently have it released anywhere (I'll eventually have the
> git repository on sv.nongnu.org), and I'm not sure if an attached
> tarball would be appreciated (I can attach it if requested), but here's
> the SYNOPSIS so you can get an idea of what it does and how it works:
>
> SYNOPSIS
>Object oriented interface
>use Text::Wrap::OO;
>
>my $wrapper = Text::Wrap::OO->new(init_tab => "\t");
>$wrapper->columns(70);
>my $wrapped = $wrapper->wrap($text);
>
>Static method interface
>use Text::Wrap::OO;
>
>my $wrapped = Text::Wrap::OO->wrap(
>{
>init_tab=> "\t",
>columns => 70,
>}, $text,
>);
>
>Exported interface
>use Text::Wrap::OO 'wrap',
>wrap => { columns => 70, -as => 'wrap70' };
>
>my $wrapped = wrap {
>init_tab=> "\t",
>columns => 60,
>}, $text;
>
>my $wrapped_70 = wrap70 {
>huge => 'overflow',
>}, $text;
>
> Thanks in advance,
> Asher
>
> P.S. https://pause.perl.org/pause/query?ACTION=pause_namingmodules seems
> to indicate that this is a good list for this type of question. Sorry if
> I was mistaken.
>
> --
> I have no doubt that it is a part of the destiny of the human race,
> in its gradual improvement, to leave off eating animals.
> -- Thoreau
>
> I prefer to send and receive mail encrypted. Please send me your
> public key, and if you do not have my public key, please let me
> know. Thanks.
>
> GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68
>
It's a fine list for that purpose. You may also seek feedback on
https://perldoc.perl.org/perlcommunity#IRC or https://www.reddit.com/r/perl/
.
The name and design seem fine to me. Just beware providing so many options
for doing the same thing that you'll have to support them all (common
mistake of the "DWIM era" of CPAN), sometimes it is better to keep things
simple and only add alternative options once they are useful.
Also make sure you are aware that CPAN distributions must be packaged a
specific way. The first few sections of
https://metacpan.org/pod/Dist::Zilla::Starter go over this and some modern
options for authoring (you don't have to use Dist::Zilla unless it fits
your approach). http://tynovsky.github.io/cpan-tutorials/ also lays out a
quick guide to authoring with Minilla.
-Dan
Re: new module version
Hi Mikhail, On Mon, 29 Oct 2012 12:42:39 +0500 Mikhail Che m@aukama.dyndns.org wrote: Hi, How to apply new version for uploaded module? PAUSE indexer status OK. Is this module yours? Are you the owner of this namespace? What is this module? Why my Edit Module Metadata on PAUSE is empty? Which one? Always Register Namespace for new versions? You don't need to register the namespace for new versions. The only advantage it gives you is being listed in the old (and now deprecated and unloved) long modules list. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Perl Humour - http://perl-begin.org/humour/ Bigamy: Having one wife too many. Monogamy: The same thing! — Unknown source. Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: new module version
Hi Shlomi Shlomi Fish wrote 2012-10-29 13:05: Hi Mikhail, On Mon, 29 Oct 2012 12:42:39 +0500 Mikhail Che m@aukama.dyndns.org wrote: Hi, How to apply new version for uploaded module? PAUSE indexer status OK. Is this module yours? Are you the owner of this namespace? What is this module? Yes, is my module lib::remote. I did upload version 0.01 and send register namespace request http://www.nntp.perl.org/group/perl.modules/2012/10/msg82917.html . Now see version 0.01 but I did upload version 0.02 and can't see this on search.cpan.org. --- Regards, Mikhail
Re: new module version
Hi Mikhail, On Mon, 29 Oct 2012 13:28:33 +0500 Mikhail Che m@aukama.dyndns.org wrote: Hi Shlomi Shlomi Fish wrote 2012-10-29 13:05: Hi Mikhail, On Mon, 29 Oct 2012 12:42:39 +0500 Mikhail Che m@aukama.dyndns.org wrote: Hi, How to apply new version for uploaded module? PAUSE indexer status OK. Is this module yours? Are you the owner of this namespace? What is this module? Yes, is my module lib::remote. I did upload version 0.01 and send register namespace request http://www.nntp.perl.org/group/perl.modules/2012/10/msg82917.html . Now see version 0.01 but I did upload version 0.02 and can't see this on search.cpan.org. I see it fine on metacpan.org: https://metacpan.org/module/lib::remote However, why is its documentation in Russian? See: * http://perl-begin.org/tutorials/bad-elements/#code_in_foreign_lang Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ List of Networking Clients - http://shlom.in/net-clients If a million Shakespeares had to write together, they would write like a monkey. — based on Stephen Wright, via Nadav Har’El. Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: new module version
Shlomi Fish wrote 2012-10-29 14:07: Hi Mikhail, On Mon, 29 Oct 2012 13:28:33 +0500 Mikhail Che m@aukama.dyndns.org wrote: Hi Shlomi Shlomi Fish wrote 2012-10-29 13:05: Hi Mikhail, On Mon, 29 Oct 2012 12:42:39 +0500 Mikhail Che m@aukama.dyndns.org wrote: Hi, How to apply new version for uploaded module? PAUSE indexer status OK. Is this module yours? Are you the owner of this namespace? What is this module? Yes, is my module lib::remote. I did upload version 0.01 and send register namespace request http://www.nntp.perl.org/group/perl.modules/2012/10/msg82917.html [2] . Now see version 0.01 but I did upload version 0.02 and can't see this on search.cpan.org. I see it fine on metacpan.org: https://metacpan.org/module/lib::remote I want see new version on cpan.org :) However, why is its documentation in Russian? See: * http://perl-begin.org/tutorials/bad-elements/#code_in_foreign_lang OK ;) Will translate later. Regards, Shlomi Fish --- Regards, Mikhail Links: -- [1] http://www.nntp.perl.org/group/perl.modules/2012/10/msg82917.html
Re: new module version
On Mon, Oct 29, 2012 at 9:28 AM, Mikhail Che m@aukama.dyndns.orgwrote: Is this module yours? Are you the owner of this namespace? What is this module? Yes, is my module lib::remote. I did upload version 0.01 and send register namespace request http://www.nntp.perl.org/**group/perl.modules/2012/10/** msg82917.htmlhttp://www.nntp.perl.org/group/perl.modules/2012/10/msg82917.html. Now see version 0.01 but I did upload version 0.02 and can't see this on search.cpan.org. It'll take some time to propagate to search.cpan.org – queries there don't go directly to pause, I imagine. The reason why your Edit Module Metadata on PAUSE is empty, is likely that the module is not registered. Did you submit an application on https://pause.perl.org/pause/authenquery?ACTION=apply_mod? Did you receive a response (and not just a copy of your proposal)? Eirik
Re: new module version
Eirik Berg Hanssen wrote 2012-10-29 14:45: On Mon, Oct 29, 2012 at 9:28 AM, Mikhail Che m@aukama.dyndns.org wrote: Is this module yours? Are you the owner of this namespace? What is this module? Yes, is my module lib::remote. I did upload version 0.01 and send register namespace request http://www.nntp.perl.org/group/perl.modules/2012/10/msg82917.html [2] . Now see version 0.01 but I did upload version 0.02 and can't see this on search.cpan.org [3]. It'll take some time to propagate to search.cpan.org [2] - queries there don't go directly to pause, I imagine. The reason why your on PAUSE is empty, is likely that the module is not registered. Did you submit an application on https://pause.perl.org/pause/authenquery?ACTION=apply_mod [4]? Yes. Did you receive a response (and not just a copy of your proposal)? Just a copy but module version 0.01 is available to install from cpan now. Eirik --- Regards, Mikhail Links: -- [1] http://www.nntp.perl.org/group/perl.modules/2012/10/msg82917.html [2] http://search.cpan.org [3] https://pause.perl.org/pause/authenquery?ACTION=apply_mod
Re: new module version
Eirik Berg Hanssen wrote 2012-10-29 14:45: On Mon, Oct 29, 2012 at 9:28 AM, Mikhail Che m@aukama.dyndns.org wrote: Is this module yours? Are you the owner of this namespace? What is this module? Yes, is my module lib::remote. I did upload version 0.01 and send register namespace request http://www.nntp.perl.org/group/perl.modules/2012/10/msg82917.html [2] . Now see version 0.01 but I did upload version 0.02 and can't see this on search.cpan.org [3]. It'll take some time to propagate to search.cpan.org [2] - queries there don't go directly to pause, I imagine. This is right. Thanks. Eirik --- Regards, Mikhail
Re: new module version
On Mon, 29 Oct 2012 14:31:03 +0500 Mikhail Che m@aukama.dyndns.org wrote: Shlomi Fish wrote 2012-10-29 14:07: Hi Mikhail, On Mon, 29 Oct 2012 13:28:33 +0500 Mikhail Che m@aukama.dyndns.org wrote: Hi Shlomi Shlomi Fish wrote 2012-10-29 13:05: Hi Mikhail, On Mon, 29 Oct 2012 12:42:39 +0500 Mikhail Che m@aukama.dyndns.org wrote: Hi, How to apply new version for uploaded module? PAUSE indexer status OK. Is this module yours? Are you the owner of this namespace? What is this module? Yes, is my module lib::remote. I did upload version 0.01 and send register namespace request http://www.nntp.perl.org/group/perl.modules/2012/10/msg82917.html [2] . Now see version 0.01 but I did upload version 0.02 and can't see this on search.cpan.org. I see it fine on metacpan.org: https://metacpan.org/module/lib::remote I want see new version on cpan.org :) It's there now - http://search.cpan.org/dist/lib-remote/ . Note that generally metacpan.org is now preferable over search.cpan.org . However, why is its documentation in Russian? See: * http://perl-begin.org/tutorials/bad-elements/#code_in_foreign_lang OK ;) Will translate later. Thanks! Regards, Shlomi Fish Regards, Shlomi Fish --- Regards, Mikhail Links: -- [1] http://www.nntp.perl.org/group/perl.modules/2012/10/msg82917.html -- - Shlomi Fish http://www.shlomifish.org/ Star Trek: We, the Living Dead - http://shlom.in/st-wtld There are no deletionists. Only Wikipedia articles which Chuck Norris allows to live. (By: joeyadams) Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: new module version
Shlomi Fish wrote 2012-10-29 16:03: On Mon, 29 Oct 2012 14:31:03 +0500 Mikhail Che m@aukama.dyndns.org wrote: Shlomi Fish wrote 2012-10-29 14:07: Hi Mikhail, On Mon, 29 Oct 2012 13:28:33 +0500 Mikhail Che m@aukama.dyndns.org wrote: Hi Shlomi Shlomi Fish wrote 2012-10-29 13:05: Hi Mikhail, On Mon, 29 Oct 2012 12:42:39 +0500 Mikhail Che m@aukama.dyndns.org wrote: Hi, How to apply new version for uploaded module? PAUSE indexer status OK. Is this module yours? Are you the owner of this namespace? What is this module? Yes, is my module lib::remote. I did upload version 0.01 and send register namespace request http://www.nntp.perl.org/group/perl.modules/2012/10/msg82917.html [2] [2] . Now see version 0.01 but I did upload version 0.02 and can't see this on search.cpan.org. I see it fine on metacpan.org: https://metacpan.org/module/lib [3]::remote I want see new version on cpan.org :) It's there now - http://search.cpan.org/dist/lib-remote/. Note that generally metacpan.org is now preferable over search.cpan.org . Nice. But is there command line utility like cpan for install from metacpan.org? However, why is its documentation in Russian? See: * http://perl-begin.org/tutorials/bad-elements/#code_in_foreign_lang [4] OK ;) Will translate later. Thanks! Regards, Shlomi Fish --- Regards, Mikhail Links: -- [1] http://www.nntp.perl.org/group/perl.modules/2012/10/msg82917.html [2] https://metacpan.org/module/lib [3] http://perl-begin.org/tutorials/bad-elements/#code_in_foreign_lang
Re: new module version
On Mon, Oct 29, 2012 at 01:03:08PM +0200, Shlomi Fish wrote: It's there now - http://search.cpan.org/dist/lib-remote/ . Note that generally metacpan.org is now preferable over search.cpan.org . Note that this is a matter of opinion, not of fact. -- David Cantrell | Enforcer, South London Linguistic Massive Feature: an incorrectly implemented bug
Re: new module version
On Mon, Oct 29, 2012 at 04:19:56PM +0500, Mikhail Che wrote: Shlomi Fish wrote 2012-10-29 16:03: metacpan.org is now preferable over search.cpan.org . Nice. But is there command line utility like cpan for install from metacpan.org? No. There isn't one for installing from search.cpan.org either. Both of those sites are just webby views of the CPAN. -- David Cantrell | Enforcer, South London Linguistic Massive The voices said it's a good day to clean my weapons
Re: new module version
David Cantrell wrote 2012-10-29 19:56: On Mon, Oct 29, 2012 at 04:19:56PM +0500, Mikhail Che wrote: Shlomi Fish wrote 2012-10-29 16:03: metacpan.org is now preferable over search.cpan.org . Nice. But is there command line utility like cpan for install from metacpan.org? No. There isn't one for installing from search.cpan.org either. Both of those sites are just webby views of the CPAN. Ok, thanks. --- Regards, Mikhail
Re: New module naming
Wow this has turned into a monster thread... ouch. On Mon, Nov 7, 2011 at 7:42 PM, Shlomi Fish shlo...@shlomifish.org wrote: Hi Sawyer, Hey. :) The problem is that using my $a and my $b will prevent the built-in $a and $b from being used and as a result is a bad idea. We should make sure that synopses and other code excerpts in the documentation of Perl modules reflect the Perl best practices, because less clueful people may be tempted to duplicate them in their own code. And then they go to online forums and ask us why their code is broken. So the lexical $a and $b here should be replaced with something less dangerous. I'm convinced. I would like to retract my disrespectful poor-taste comment I made earlier. And no, I'm not being cynical. :) We honestly don't have to comment on *everything* people say and do. (and I probably shouldn't have commented on what you said either, so apologies for that) Well, I hope I didn't also make the same mistake (again). Not in my opinion. Thanks for correcting me. :) s.
Re: New module naming
Hello Sawyer, On Tue, 8 Nov 2011 17:38:56 +0200 sawyer x xsawy...@gmail.com wrote: Wow this has turned into a monster thread... ouch. On Mon, Nov 7, 2011 at 7:42 PM, Shlomi Fish shlo...@shlomifish.org wrote: The problem is that using my $a and my $b will prevent the built-in $a and $b from being used and as a result is a bad idea. We should make sure that synopses and other code excerpts in the documentation of Perl modules reflect the Perl best practices, because less clueful people may be tempted to duplicate them in their own code. And then they go to online forums and ask us why their code is broken. So the lexical $a and $b here should be replaced with something less dangerous. I'm convinced. I would like to retract my disrespectful poor-taste comment I made earlier. And no, I'm not being cynical. :) Well, I'm glad we agree now, and I should note that your comment wasn't that bad. You've also raised some points which made me clarify why I think so in this thread's case. We honestly don't have to comment on *everything* people say and do. (and I probably shouldn't have commented on what you said either, so apologies for that) Well, I hope I didn't also make the same mistake (again). Not in my opinion. Thanks for correcting me. :) s. :-). Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Star Trek: We, the Living Dead - http://shlom.in/st-wtld JATFM == “Just answer the fabulous man” Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: New module naming
Hi Trystan, On Sun, 6 Nov 2011 16:28:03 -0600 Trystan trysta...@gmail.com wrote: Hi. I've written few libraries I'd like to release on CPAN and I'm looking for some advice on how to name them. I found this idea in Head First OOADhttp://headfirstlabs.com/books/hfooad/, chapter 5. It's somewhat like a very simple version of Key-Value Codinghttp://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/KeyValueCoding/Articles/Overview.html%23//apple_ref/doc/uid/20001838-SW1. It's also very similar to Object::Generichttp://search.cpan.org/%7Ejmahoney/Object-Generic-0.13/lib/Object/Generic.pmbut I didn't use AUTOLOAD and I implemented 'equals' and 'contains' methods in order to make the objects searchable within a container. Here's an example: my $a = tbd_name::Object-new(); my $b = tbd_name::Object-new(); You shouldn't call lexical variables $a and $b: http://perl-begin.org/tutorials/bad-elements/#vars-a-and-b Sorry I cannot help with the actual issue. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Chuck Norris/etc. Facts - http://www.shlomifish.org/humour/bits/facts/ I may be a geek, but I’m a true Klingon geek‐warrior! And a true Klingon geek warrior ALWAYS bottom‐posts. Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: New module naming
What about Object::KVC, Object::KVC::String, Object::KVC::List? Trystan wrote: I found this idea in Head First OOAD http://headfirstlabs.com/books/hfooad/, chapter 5. It's somewhat like a very simple version of Key-Value Coding http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/KeyValueCoding/Articles/Overview.html%23//apple_ref/doc/uid/20001838-SW1. It's also very similar to Object::Generic http://search.cpan.org/%7Ejmahoney/Object-Generic-0.13/lib/Object/Generic.pm but I didn't use AUTOLOAD and I implemented 'equals' and 'contains' methods in order to make the objects searchable within a container. Here's an example: my $a = tbd_name::Object-new(); my $b = tbd_name::Object-new(); $a-set( ID, tbd_name::String-new(1234a) ); $b-set( ID, tbd_name::String-new(1234a) ); print $a-get(ID); $a-equals($b) ? print yes; $container = tbd_name::List-new(); $container-add($a); $container-search($b); #which returns $a What do I call this thing? I'm thinking the namespace would be 'KeyValue::' or 'KeyVal::' Would that make sense? (That namespace doesn't seem to be used.) Should this go in 'Class::'? Thanks. -- Serguei Trouchelle
Re: New module naming
On Mon, Nov 7, 2011 at 10:07 AM, Shlomi Fish shlo...@shlomifish.org wrote: You shouldn't call lexical variables $a and $b: That was a completely pointless comment, Shlomi. He's trying to showcase an action on two objects that have the exact same level of importance and relevance. Calling them $a and $b is the same as $homer and $marge or $object1 and $object2 or $first and $second or anything of that order. This is a case where $a and $b makes absolute sense. It is also the same case as Perl's sort() function that uses $a and $b to indicate two values of the same importance. We honestly don't have to comment on *everything* people say and do. (and I probably shouldn't have commented on what you said either, so apologies for that) Have a good day, s.
Re: New module naming
What about Object::KVC, Object::KVC::String, Object::KVC::List? KVC it is. I had actually been considering that. In the Object::Generic documentation the author says his module should have been in the Class:: namespace. What is the difference between the Object:: namespace and Class:: namespace? Thanks.
Re: New module naming
* Trystan trysta...@gmail.com [2011-11-06 23:30]: I found this idea in Head First OOADhttp://headfirstlabs.com/books/hfooad/, chapter 5. It's somewhat like a very simple version of Key-Value Codinghttp://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/KeyValueCoding/Articles/Overview.html%23//apple_ref/doc/uid/20001838-SW1. It's also very similar to Object::Generichttp://search.cpan.org/%7Ejmahoney/Object-Generic-0.13/lib/Object/Generic.pmbut I didn't use AUTOLOAD and I implemented 'equals' and 'contains' methods in order to make the objects searchable within a container. Here's an example: my $a = tbd_name::Object-new(); my $b = tbd_name::Object-new(); $a-set( ID, tbd_name::String-new(1234a) ); $b-set( ID, tbd_name::String-new(1234a) ); print $a-get(ID); $a-equals($b) ? print yes; $container = tbd_name::List-new(); $container-add($a); $container-search($b); #which returns $a What do I call this thing? Uhm. So when would I ever use this over a simple hash?
Re: New module naming
On Mon, Nov 7, 2011 at 12:39 PM, Aristotle Pagaltzis pagalt...@gmx.dewrote: * Trystan trysta...@gmail.com [2011-11-06 23:30]: I found this idea in Head First OOADhttp://headfirstlabs.com/books/hfooad/, chapter 5. It's somewhat like a very simple version of Key-Value Coding http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/KeyValueCoding/Articles/Overview.html%23//apple_ref/doc/uid/20001838-SW1 . It's also very similar to Object::Generic http://search.cpan.org/%7Ejmahoney/Object-Generic-0.13/lib/Object/Generic.pm but I didn't use AUTOLOAD and I implemented 'equals' and 'contains' methods in order to make the objects searchable within a container. Here's an example: my $a = tbd_name::Object-new(); my $b = tbd_name::Object-new(); $a-set( ID, tbd_name::String-new(1234a) ); $b-set( ID, tbd_name::String-new(1234a) ); print $a-get(ID); $a-equals($b) ? print yes; $container = tbd_name::List-new(); $container-add($a); $container-search($b); #which returns $a What do I call this thing? Uhm. So when would I ever use this over a simple hash?
Re: New module naming
-Original Message- From: Shlomi Fish shlo...@shlomifish.org Date: Mon, 7 Nov 2011 19:42:35 +0200 To: sawyer x xsawy...@gmail.com Cc: Perl Module Authors List module-authors@perl.org Subject: Re: New module naming Hi Sawyer, On Mon, 7 Nov 2011 13:36:58 +0200 sawyer x xsawy...@gmail.com wrote: On Mon, Nov 7, 2011 at 10:07 AM, Shlomi Fish shlo...@shlomifish.org wrote: You shouldn't call lexical variables $a and $b: We honestly don't have to comment on *everything* people say and do. (and I probably shouldn't have commented on what you said either, so apologies for that) Well, I hope I didn't also make the same mistake (again). Yeah, you did. Quite frankly, I have been lurking on this list for years - first through the web then as an actual subscriber as I currently try to find time in my schedule to contribute a module that I finally believe to be worthy of adding to CPAN. I have seen a multitude of posts from you, Shlomi, and the vast majority of them have been of the them of I don¹t like the way you are doing it, because it's not the way *I* would do it, but I really don't have a better way of doing it myself to contribute. Nobody likes a know-it-all. Worse yet, nobody likes a know-it-all without the who doesn't have the credentials to back up their b.s. In this particular case, pretty much everyone clearly understood that what was given was a GENERIC EXAMPLE, not real code. It didn't call for code review, comment or criticism on the use of variables or their naming. What was requested was feedback on the naming of the MODULE. There is probably a reason why your suggestions are ignored, for everything from improving the perl.org site to redesigning the perl training documentation to ridiculous commentary like this. Dig deep and you can probably figure it out. Bob Parker bob at perldevgeek.com Regards, Shlomi Fish Have a good day, s. -- - Shlomi Fish http://www.shlomifish.org/ The Case for File Swapping - http://shlom.in/file-swap You name it COBOL does not have it. Please reply to list if it's a mailing list post - http://shlom.in/reply .
Politics Personalities - was Re: New module naming
From: Eirik Berg Hanssen ebhans...@cpan.org Reply-To: ebhans...@cpan.org Date: Mon, 7 Nov 2011 21:39:15 +0100 To: Bob Parker b...@perldevgeek.com Cc: Shlomi Fish shlo...@shlomifish.org, Perl Module Authors List module-authors@perl.org Subject: Re: New module naming On Mon, Nov 7, 2011 at 9:28 PM, Bob Parker b...@perldevgeek.com wrote: In this particular case, pretty much everyone clearly understood that what was given was a GENERIC EXAMPLE, not real code. It didn't call for code review, comment or criticism on the use of variables or their naming. What was requested was feedback on the naming of the MODULE. If we're still talking about the generic example: Publically available code with lexical $a or $b should always come with a don't do this (unless you know why you should not do this) warning. Then again, if we're now talking about what was requested, I'll just note that your opinion of Shlomi Fish was not. Perhaps you are a fan of the guy, perhaps not - I don't know you. What I do know is that for the past several years, I have seen what should have been basic and common sense discussions degenerate into personality wars because of Shlomi Fish. So sue me if I have the balls to call him out on it. Note that I was not the first, I simply elaborated on someone else's comment. Frankly, I am tired of so many on this list acting like children. Me, me, me instead of perl, perl, perl. People getting blacklisted because they dare to speak their minds. Others, with totally valid and valuable contributions being totally ignored because their ideas are not popular. I *thought* that we had gone beyond this petty stuff. Clearly I was was wrong. Eirik
Re: New module naming
Uhm. So when would I ever use this over a simple hash? Well I used it because the application I'm working on has a data model with a lot of variation (I did this instead of creating a massive class hierarchy). The accessors are the hash key scalar string. The 'equals' and 'contains' methods are delegated to the value objects when keys are eq. (yes a wrapper object is required for the value but this could be automated.)This allows fairly complex searches of a container of objects. This is based on an idea from a Java tutorial. I think it works better in Perl than Java because the value objects can be of arbitrary type allowing the composite hash based object to be more complex if needed.
Re: Politics Personalities - was Re: New module naming
* Bob Parker b...@perldevgeek.com [2011-11-07 22:15]: Perhaps you are a fan of the guy, perhaps not - I don't know you. Perhaps it doesn’t even matter. Perhaps you can be a decent person to someone you dislike. What I do know is that for the past several years, I have seen what should have been basic and common sense discussions degenerate into personality wars because of Shlomi Fish. So sue me if I have the balls to call him out on it. Note that I was not the first, I simply elaborated on someone else's comment. No. You had the no-balls to come out behind someone else and follow up on an apology by beating on him some more. Congratulations, I hope you’re proud. Frankly, I am tired of so many on this list acting like children. Me, me, me instead of perl, perl, perl. People getting blacklisted because they dare to speak their minds. Others, with totally valid and valuable contributions being totally ignored because their ideas are not popular. I *thought* that we had gone beyond this petty stuff. Clearly I was was wrong. Pot, kettle. -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: New module naming
On Mon, Nov 7, 2011 at 9:28 PM, Bob Parker b...@perldevgeek.com wrote: In this particular case, pretty much everyone clearly understood that what was given was a GENERIC EXAMPLE, not real code. It didn't call for code review, comment or criticism on the use of variables or their naming. What was requested was feedback on the naming of the MODULE. If we're still talking about the generic example: Publically available code with lexical $a or $b should always come with a don't do this (unless you know why you should not do this) warning. Then again, if we're now talking about what was requested, I'll just note that your opinion of Shlomi Fish was not. Eirik
Re: New module naming
On Mon, Nov 7, 2011 at 12:36 PM, sawyer x xsawy...@gmail.com wrote:
This is a case where $a and $b makes absolute sense. It is also the same
case as Perl's sort() function that uses $a and $b to indicate two values
of the same importance.
... except declaring them as lexicals still _breaks_ their use in sort {
} in the same scope.
... and _silently_ breaks a naïve mysort { } in the same scope. Even
with strict and warnings!
This is a case where pointing out the shortcomings of lexical $a and $b
makes absolute sense. Frankly, every sample code with lexical $a or $b is
such a case.
Eirik
Re: New module: Alien::SDL
On Fri, Aug 7, 2009 at 8:21 AM, Kartik Thakorethakore.kar...@gmail.com wrote: either source or binaries. Since this will be my first CPAN module, how do I upload the module? I already have a cpan account. Read the instructions: https://pause.perl.org/pause/authenquery?ACTION=pause_04about Upload here: https://pause.perl.org/pause/authenquery?ACTION=add_uri -- David
Re: New Module
* Jonathan Rockway j...@jrock.us [2009-05-03 08:00]: * On Sat, May 02 2009, Aristotle Pagaltzis wrote: Yeah, if there are thousands of other programmers using a module, then its name can be pretty much anything. If more or less the only marketing it has is search.cpan.org results page, then most potential users will miss it unless its name is descriptive and based on keywords someone might actually use to search for something like it. This is why Perl people should blog more. Agreed, that helps up to a point. But you can’t natter on about *every* module at the same level of noise. Plus, the number of Perl programmers who don’t mingle with the community and won’t be reached by blog buzz dwarfs the community core; for them, only the slow trickle of mindshare among peers will work. (Actually, s/Perl// – it’s true of all programming communities.) But it’s them who give Perl coin in corporate environments, not the core community directly. Basically I think that irrespective of other marketing efforts, the Zen of Comprehensive Archive Networks remains valid. Ultimately I think the smaller and more focussed a module, the more sense it makes to name it neutrally and descriptively. For complex packages, a more googlable name is more useful, since their mindshare flows from different channels. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: New Module
On May 3, 2009, at 6:54 AM, Aristotle Pagaltzis wrote: * Jonathan Rockway j...@jrock.us [2009-05-03 08:00]: This is why Perl people should blog more. Agreed, that helps up to a point. But you can’t natter on about *every* module at the same level of noise. I vehemently agree. At the risk of derailing this thread, I'll digress to say the Iron Man blogging competition has actually made me read fewer posts -- my initial impression was that the quality of a post was lower if it mentioned Iron Man in the first sentence. If you blog because you are inspired to say something important to the community, then I want to read it. If you blog every time you release a module, or just because mst told you to, then you are just lowering the signal-to-noise ratio. High S/N means optimizing quality/quantity. Jonathan's simply-stated opinion pushes to increase the denominator, which may help increase the visibility of the community but hurts inside the community. Chris
Re: New Module
* Chris Dolan ch...@chrisdolan.net [2009-05-03 16:25]: If you blog because you are inspired to say something important to the community, then I want to read it. If you blog every time you release a module, or just because mst told you to, then you are just lowering the signal-to-noise ratio. High S/N means optimizing quality/quantity. Jonathan's simply-stated opinion pushes to increase the denominator, which may help increase the visibility of the community but hurts inside the community. I don’t know that it’s that simple. The Iron Man thing has caused a lot of personal weblogs to pop up and there’ve been plenty of genuinely interesting posts in them. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: New Module
2009/5/2 Jonathan Rockway j...@jrock.us * On Thu, Apr 30 2009, Ivan Wills wrote: My module uses template toolkit templates. By manage I mean provide a command line tool to supply template parameters and print out processed templates. My long term goal is to provide a infrastructure to produce commands like catalyst.pl or h2xs which uses templates, instead of being coded into the scripts/modules of those commands, so that you can override templates if you don't like the defaults those programs use. I would use the App:: namespace for this. In the end, it doesn't really matter what you name your module. Concentrate on writing it, and worry about naming later (or never). People will find your module, even if the name doesn't make sense. (Examples: Moose, Catalyst.) Also, don't worry about the people that want you to justify the module's existence by explaining how it's different from other things. The other things are worth considering (the best code is code you didn't have to write), but if you don't like the existing stuff and you can't fix it, write your own. You don't need to be accountable to anyone but yourself. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$ Thanks, that's just the sort of response I needed to hear :-) -- email/jabber: ivan.wi...@gmail.com / / _ _ / \ / | | | | /\/ \_| | |
Re: New Module
* Jonathan Rockway j...@jrock.us [2009-05-01 19:15]: People will find your module, even if the name doesn't make sense. (Examples: Moose, Catalyst.) Yeah, if there are thousands of other programmers using a module, then its name can be pretty much anything. If more or less the only marketing it has is search.cpan.org results page, then most potential users will miss it unless its name is descriptive and based on keywords someone might actually use to search for something like it. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: New Module
* On Sat, May 02 2009, Aristotle Pagaltzis wrote: * Jonathan Rockway j...@jrock.us [2009-05-01 19:15]: People will find your module, even if the name doesn't make sense. (Examples: Moose, Catalyst.) Yeah, if there are thousands of other programmers using a module, then its name can be pretty much anything. If more or less the only marketing it has is search.cpan.org results page, then most potential users will miss it unless its name is descriptive and based on keywords someone might actually use to search for something like it. This is why Perl people should blog more. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: New Module
* On Thu, Apr 30 2009, Ivan Wills wrote: My module uses template toolkit templates. By manage I mean provide a command line tool to supply template parameters and print out processed templates. My long term goal is to provide a infrastructure to produce commands like catalyst.pl or h2xs which uses templates, instead of being coded into the scripts/modules of those commands, so that you can override templates if you don't like the defaults those programs use. I would use the App:: namespace for this. In the end, it doesn't really matter what you name your module. Concentrate on writing it, and worry about naming later (or never). People will find your module, even if the name doesn't make sense. (Examples: Moose, Catalyst.) Also, don't worry about the people that want you to justify the module's existence by explaining how it's different from other things. The other things are worth considering (the best code is code you didn't have to write), but if you don't like the existing stuff and you can't fix it, write your own. You don't need to be accountable to anyone but yourself. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: New Module
2009/4/29 Andy Armstrong a...@hexten.net On 29 Apr 2009, at 11:59, Ivan Wills wrote: I have most converted a script that I have long used for managing templates (for files like perl files, XHTML etc) into a package that I can upload to CPAN. It includes a script to actually pass the templates. At the moment it is called Template::CMD. I was wondering if this is the correct/best name for it? I think the Template namespace pretty much belongs to Template Toolkit. Can you expand on what 'managing templates' amounts to? -- Andy Armstrong, Hexten My module uses template toolkit templates. By manage I mean provide a command line tool to supply template parameters and print out processed templates. My long term goal is to provide a infrastructure to produce commands like catalyst.pl or h2xs which uses templates, instead of being coded into the scripts/modules of those commands, so that you can override templates if you don't like the defaults those programs use. Ivan Wills -- email/jabber: ivan.wi...@gmail.com / / _ _ / \ / | | | | /\/ \_| | |
Re: New Module
Ivan Wills ha scritto: 2009/4/29 Andy Armstrong a...@hexten.net mailto:a...@hexten.net On 29 Apr 2009, at 11:59, Ivan Wills wrote: I have most converted a script that I have long used for managing templates (for files like perl files, XHTML etc) into a package that I can upload to CPAN. It includes a script to actually pass the templates. At the moment it is called Template::CMD. I was wondering if this is the correct/best name for it? I think the Template namespace pretty much belongs to Template Toolkit. Can you expand on what 'managing templates' amounts to? -- Andy Armstrong, Hexten My module uses template toolkit templates. By manage I mean provide a command line tool to supply template parameters and print out processed templates. Which is the added values of your solution with respect using tpage/ttree ? Best, Marco. My long term goal is to provide a infrastructure to produce commands like catalyst.pl or h2xs which uses templates, instead of being coded into the scripts/modules of those commands, so that you can override templates if you don't like the defaults those programs use. Ivan Wills -- email/jabber: ivan.wi...@gmail.com mailto:ivan.wi...@gmail.com / / _ _ / \ / | | | | /\/ \_| | |
Re: New Module
On 29 Apr 2009, at 11:59, Ivan Wills wrote: I have most converted a script that I have long used for managing templates (for files like perl files, XHTML etc) into a package that I can upload to CPAN. It includes a script to actually pass the templates. At the moment it is called Template::CMD. I was wondering if this is the correct/best name for it? I think the Template namespace pretty much belongs to Template Toolkit. Can you expand on what 'managing templates' amounts to? -- Andy Armstrong, Hexten
Re: New module idea for intranet location of ipaddresses
On Fri, Mar 7, 2008 at 9:18 AM, Andrew Stringer [EMAIL PROTECTED] wrote: I am not sure how an external config file fits with a perl module though. Should a module be entirely self contained? Well, one way is to do the way Perl itself (Config.pm) and CPAN.pm do it - store the configuration in a Perl module. CPAN lets you put it in a MyConfig.pm file under your home directory or have a system-wide CPAN::Config module. But I think the most flexible way would be to just make the user pass the configuration in as an argument, perhaps as a hashref. In the docs, you could suggest that the user store the configuration in a Perl, YAML, or XML file but pass the information in as a hash. I think that makes it easiest for the user to control how they might want to handle configuration in their own environment.
Re: New module name
Greetings. David Golden [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Oleg, thanks for tackling such a tricky subject. Would you consider patching Win32API::File instead of releasing a new module? Or working with the current maintainer, demerphq, on improvements? I think that would be a better approach. I lean in favor of new module, because I think that it would have different approach to task. Win32API::File is low-lever here's your access to internals, do what you want. It doesn't do any recoding or reformating (well, almost) for both input and output to make it more Perl-like, it doesn't handle Unicode or other argument errors and that's probably what it is intended to do - if someone wants quick access to API and knows exactly what he feeding there and what he gets back, Win32API::File is for him. I intend to make my module just as easy to use as normal copy or move functions from perlfunc. It will take care of checking arguments, croaking when user passes bytes instead of strings or undefined handles and will do other stuff people may not want from module that supposed to just give access to API. Another reason is that Win32API::File is partially XS and I'm not ready to mess with it just yet. -- Oleg Rowaa[SR13] V. Volkov
Re: New module name
On 9/19/06, David Golden [EMAIL PROTECTED] wrote: Oleg V. Volkov wrote: Greetings. One day when I was tired from being (almost) unable to work with Unicode file names on Win32, I wrote a module with wrappers around Win32 API function that uses Win32::API to actually import them from .dlls. I did not use Win32API::File because it doesn't provide convient way to use Perl unicode strings as arguments, nor does it check for some errors that I feel should be critical, nor does it parse structures in output and, finally, it simply does not implement several function I needed, like FindFirstFileW, for example. So, right now my module have some *W functions implemented, namely: MoveFileW CopyFileW FindFirstFileW FindNextFileW FindClose. Glob function based on last three *W win32api_glob (which probably will be moved in future to sub-module ::Glob and made do be as close as posible to File::Glob functions), some helper functions that pack/unpack structures based on C-struct defenitions parsed verbatim from MSDN and I plan to implement other *W functions, especially those not covered by Win32API::File at all. Only important limitation is that I will only use *W functions, unless function is neutral, like FindClose. Right now I think Win32::FileW would be a good name for this module. Is there any problems with such name or suggestions of better one? Oleg, thanks for tackling such a tricky subject. Would you consider patching Win32API::File instead of releasing a new module? Or working with the current maintainer, demerphq, on improvements? I think that would be a better approach. I agree. Id also like to see more detail about the perceived weaknesses in Win32API::File. Also, id say that doing direct bindings against the Win API is superior to using Win32::API, although im probably a touch biased. Yves -- perl -Mre=debug -e /just|another|perl|hacker/
Re: New module name
Oleg V. Volkov wrote: I lean in favor of new module, because I think that it would have different approach to task. Win32API::File is low-lever here's your access to internals, do what you want. It doesn't do any recoding or reformating (well, almost) for both input and output to make it more Perl-like, it doesn't handle Unicode or other argument errors and that's probably what it is intended to do - if someone wants quick access to API and knows exactly what he feeding there and what he gets back, Win32API::File is for him. I intend to make my module just as easy to use as normal copy or move functions from perlfunc. It will take care of checking arguments, croaking when user passes bytes instead of strings or undefined handles and will do other stuff people may not want from module that supposed to just give access to API. Another reason is that Win32API::File is partially XS and I'm not ready to mess with it just yet. I'd like to see a mixture of high and low level features available in one nicely done module than having features scattered across various Win32::File* modules. A word of warning about Win32::API -- the current release doesn't build on MinGW, which prevents it from working on Vanilla Perl. There's an unreleased patch, but it needs a new maintainer. See: http://win32.perl.org/wiki/index.php?title=Vanilla_Perl_Problem_Modules for some details. Regards, David
Re: New module name
Greetings.
I agree. Id also like to see more detail about the perceived
weaknesses in Win32API::File. Also, id say that doing direct bindings
against the Win API is superior to using Win32::API, although im
probably a touch biased.
I'll just use an example. Here's the script my friend asked me to write - it
scans current directory and converts japanese filenames with Text::Kakasi to
romaji:
use Encode;
use Text::Kakasi;
use Win32::FileW;
use strict;
use warnings;
my @keys=qw(-Ha -Ka -Ja -Ea -ka -s);
my $k=Text::Kakasi-new(@keys, '-iutf8', '-outf8');
foreach my $oldname (win32api_glob('*')){
my $newname=$k-get($oldname);
if($oldname eq $newname) { next; }
unless(MoveFileW($oldname, $newname)){
win32api_print ERR $oldname: failed to rename to $newname: $!\n;
} else {
win32api_print OK $oldname: renamed to $newname\n;
}
}
Try rewriting it with Win32API::File.
--
Oleg Rowaa[SR13] V. Volkov
Re: New module File::SlurpCache - new CPAN distro or merge in existing?
Paul LeoNerd Evans wrote: Following the resounding success [i.e. nobody complained] of my File::StatCache module sitting in the File-StatCache CPAN distribution, I'd now like to follow it up with a second module. This module builds on top of the first, implementing a read cache. Simple behaviour - give it a filename, it returns the entire contents in one scalar. I propose to call it File::SlurpCache [given as File::Cache and Cache::File both already exist]. But where to put it? * In its own distribution, again like File-StatCache, containing only one .pm file * In the same File-StatCache one, as they are likely to be used together What's the advantage of implementing your own read caching instead of letting the OS handle it? Will this effectively cache twice, once manually and once by the OS, and cost double memory? Regards, David
Re: New Module Proposal - Math::Interval
Brendan Leber wrote: First, let me apologize for my extremely late reply. Right after I started receiving replies I suffered some pretty serious system failures. I'm now back and replying to old messages. B On Mar 2, 2006, at 9:20 AM, Eric Wilhelm wrote: It sounds like this usage is part of the foundation (if not base) class Math::Interval which Brendan will need even though he might not be working directly on those bits. Yes, the foundation of the class will have functions that support traditional interval functions such as overlap() and intersect(). Out of curiosity, is there a common agreement on these 'traditional interval functions'? The most referenced proposal I'm aware of are the so called Allen relations: Maintaining Knowledge about Temporal Intervals by James F. Allen They are - as the title suggests - somewhat biased towards temporal types (e.g. relation 'during'). A perl implementation is done in Date::Interval: http://search.cpan.org/~ktorp/Interval.0.03/Interval.pm Although the book Temporal Data and the Relational Model by C.J. Date, Hugh Darwen, Nikos Lorentzos http://books.google.com/books?ie=UTF-8vid=ISBN1558608559id=grTubz0fjSECpg=PA91lpg=PA91lsig=PQpCSlzWNl_uS66gfX3Lw2RK-WY is also biased towards temporal types, the authors generalized the interval type: it's a type generator parameterized by a point type. By the way, 'during' was renamed to 'includes'. I have to admit I like their proposal. Are there other essential sources worth to consider? Steffen Goeldner
Re: New Module Proposal - Math::Interval
First, let me apologize for my extremely late reply. Right after I started receiving replies I suffered some pretty serious system failures. I'm now back and replying to old messages. B On Mar 2, 2006, at 9:20 AM, Eric Wilhelm wrote: It sounds like this usage is part of the foundation (if not base) class Math::Interval which Brendan will need even though he might not be working directly on those bits. Yes, the foundation of the class will have functions that support traditional interval functions such as overlap() and intersect(). Brendan, do you have some example code? Maybe some code of what you're trying to do without the module and corresponding snippets for how you would like the code to look with the module? Not at this time. I had finished the basic support that is required and was about to delve into the implementation of the arithmetic when I was sidetracked. (See above. ;) Error bars are a special case of subsets on the real number line in that they are rounded to a given precision. So, I would expect Math::Interval to provide basic arithmetic between intervals as well as between numbers and intervals: my $d = Math::Interval-new(3.2, 4.2); my $r = $d + 7; # returns an interval [10.2,11.2] # adding intervals adds the endpoints (ala Math::Vec), right? my $d = Math::Interval-new(2,4) + Math::Interval-new(3,8); # returns an interval [5,12] This is how I envision arithmetic will be implemented. Using Math::BigInt for inspiration I am implementing the operations as class functions and then I'll use override to add support for the various operators. And then you have intersect(), overlap(), etc for those dealing purely in interval manipulations, but Brendan wants to generate some error bars, so he needs Math::ConfidenceInterval, where most of the calculations return a new Math::Interval object: my $conf = Math::ConfidenceInterval-new(0.001); # 0.001 accuracy my $d = $conf-divide(1,3); # returns a Math::Interval-new(0.333, 0.334); You don't need to set any accuracy bounds when performing Interval Arithmetic. The errors that are introduced are a result of IEEE 784 limitations when representing floating point numbers. The way this example would look is: # a singleton is an Interval with a zero width. # the upper and lower bounds are the same. my $num = Math::Interval-singleton(1); # [1; 1] my $den = Math::Interval-singleton(3); # [3; 3] my $result = $num / $den; # implemented as $num-div($den); # result is approximately [0.; 0.3334] Maybe Brendan isn't planning to flesh-out Math::Interval right now, but someone that wants to do that can either send him patches or take over maintenance of it. I certainly don't think he should be using something like Math::ConfidenceInterval::Interval when a generic Interval can be used to represent his results and with a few more methods could also be applied to the subsets manipulation interval problem. It's all a matter of time. My plan is to keep fleshing out Math::Interval as I have time. The first release is going to support the base functions and the four basic arithmetic operations, +, -, * and /. If anyone else finds the code useful I would welcome contributions. After considering the messages I've received I think the layout should be: Math::Interval - The base support required by the other modules. This module could be used alone to support the traditional concept of intervals on the number line. Math::Interval::Arithmetic - Functions for performing arithmetic with Intervals. Math::Interval::Functions - Support for trig, logarithmic and other functions with Intervals. Math::Interval::Vector - Support for operations on vectors of Intervals. Math::Interval::Matrix - Support for operations on matrices of Intervals. The first two modules would be the initial release and I would release the other modules when they are ready. B -- Brendan Leber [EMAIL PROTECTED] If success or failure of this planet and of human beings depended on how I am and what I do... How would I be? What would I do? -- R. Buckminster Fuller
Re: New Module Proposal - Math::Interval
Orton, Yves writes: Thus, having some math background one would identify Math::Interval::Arithmetic (or maybe more proper, Math::IntervalArithmetic) at a glance in a search for interval. Imo the former form should be heavily preferred over the latter. Math::Interval admits the possibility that there could be a wide range of modules related to intervals. Math::IntervalArithmetic Does not. I completely agree with you if all of these (perhaps theoretical) modules _are_ related to intervals, and intervals in the same sense of the word as each other. But if these modules are actually dealing with different concepts (I've only been skimming this thread -- I'm not really mathsy enough to understand it -- but I think that might be the case) that only co-incidentally share a name then actually there's nothing to be gained in grouping them together. Actually, quite the reverse: there's benefit in splitting them by name into their 2 concepts. So having Math::FooInterval and Math::BarInterval as name-spaces would work for me, for suitable values of Foo and Bar which help to disambiguate the words. But similarly, if one of the meanings of interval is in more common use such that it's the concept mathematicians tend to refer to by that name without any disambiguating adjectives then it also makes sense to have Math::Interval for that concept and Math::FooInterval (or Math::InvervalFoo) for t'other one. So I think Math::Interval::Arithmetic or Math::IntervalArithmetic could be better, depending on whether it's dealing with arithmetic on the same concept as Math::Interval deals with, or whether it's a different concept entirely. Not only that but CamelHump identifiers are considered to bad style in the eyes of much of the community. It is harder for a coder to enter style-heaven than it is to fit a CamelHump through the eye of the community? Smylers
Re: New Module Proposal - Math::Interval
* Smylers [EMAIL PROTECTED] [2006-03-04 12:50]:
Orton, Yves writes:
Not only that but CamelHump identifiers are considered to bad
style in the eyes of much of the community.
It is harder for a coder to enter style-heaven than it is to fit
a CamelHump through the eye of the community?
++
Laughing,
--
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: New Module Proposal - Math::Interval
* Orton, Yves [EMAIL PROTECTED] [2006-03-03 11:05]: Ah, yeah, EUMM, ok i use that one. The rest, never or rarely. Yeah, but they’re all best-of-breed modules that someone out there who is not you uses all the time. And I still think that form sucks. :-) Fine. :-) What else do you suggest for multi-word names? Always `::`-separating the words? Somehow, while this particular name is absolutely correctly chosen, I find Gtk2::Ex::Simple::List rather hard on my fingers. Gtk2::SimpleList was significantly easier to type, though not a good name in retrospect. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
RE: New Module Proposal - Math::Interval
Title: RE: New Module Proposal - Math::Interval Ken Williams wrote on Thursday, March 02, 2006 4:28 AM On Feb 26, 2006, at 6:46 PM, Brendan Leber wrote: First I need to explain a bit about intervals. In this context an interval is a new type of number just like a complex. Intervals are used to represent values in calculations where the answer can not be exactly represented. For example, the quantity 1/3 does not have an exact binary representation so you must round the answer to the nearest representable value. When evaluating calculations with an interval the results are rounded out so that the real answer is somewhere between a lower and upper bound. (The lower bound is rounded down toward negative infinity and the upper bound is rounded up to positive infinity.) So dividing 1 by 3 could result in the interval [0.333; 0.334]. If you want to learn more the best place to start is at: http://www.cs.utep.edu/interval-comp/ I fear that the name interval might be somewhat misleading here. If I saw Math::Interval on CPAN, I'd expect it to deal with connected subsets of the real number line, and to support methods like intersect(), overlaps(), contains(), and so on. This is the sense that we'd find in, say, the Rivest/Cormen/et-al algorithms book. I agree. Your sense of intervals seems rather to be more akin to error bars on a calculated variable, right? Is this interpretation of intervals necessarily incompatible with the more traditional sense - in other words, could a single interface support both notions? If not, I might suggest something like Math::CalcInterval or something like that, so people know it's this calculational sense that the code deals with. Or maybe Math::Interval::Compute? Allowing Math::Interval to provide intersect(), overlaps(), contains() Yves
Re: New Module Proposal - Math::Interval
On Mar 2, 2006, at 4:28, Ken Williams wrote: Hi Brendan, On Feb 26, 2006, at 6:46 PM, Brendan Leber wrote: First I need to explain a bit about intervals. In this context an interval is a new type of number just like a complex. Intervals are used to represent values in calculations where the answer can not be exactly represented. For example, the quantity 1/3 does not have an exact binary representation so you must round the answer to the nearest representable value. When evaluating calculations with an interval the results are rounded out so that the real answer is somewhere between a lower and upper bound. (The lower bound is rounded down toward negative infinity and the upper bound is rounded up to positive infinity.) So dividing 1 by 3 could result in the interval [0.333; 0.334]. If you want to learn more the best place to start is at: http:// www.cs.utep.edu/interval-comp/ I fear that the name interval might be somewhat misleading here. If I saw Math::Interval on CPAN, I'd expect it to deal with connected subsets of the real number line, and to support methods like intersect(), overlaps(), contains(), and so on. This is the sense that we'd find in, say, the Rivest/Cormen/et-al algorithms book. Agreed. AFAIK the canonical name for this topic is Interval Arithmetic http://en.wikipedia.org/wiki/Interval_arithmetic#Interval_arithmetic which is the basis of Interval Analysis. Thus, having some math background one would identify Math::Interval::Arithmetic (or maybe more proper, Math::IntervalArithmetic) at a glance in a search for interval. Additionally the name suggests arithmetic-like operations on intervals to whom does not know that such a thing exists. That still may suggest set-like operations to some, but the name would be already correct and specific and the docs would clarify that. -- fxn
RE: New Module Proposal - Math::Interval
Title: RE: New Module Proposal - Math::Interval Thus, having some math background one would identify Math::Interval::Arithmetic (or maybe more proper, Math::IntervalArithmetic) at a glance in a search for interval. Imo the former form should be heavily preferred over the latter. Math::Interval admits the possibility that there could be a wide range of modules related to intervals. Math::IntervalArithmetic Does not. Not only that but CamelHump identifiers are considered to bad style in the eyes of much of the community. Yves
Re: New Module Proposal - Math::Interval
On Thu, March 2, 2006 9:19 am, Spencer Ogden said: This type of interval is also know as a Confidence Interval. Math::Statistics::Confidence? Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ---
Re: New Module Proposal - Math::Interval
* Orton, Yves [EMAIL PROTECTED] [2006-03-02 12:20]: Not only that but CamelHump identifiers are considered to bad style in the eyes of much of the community. So Math::Intervalarithmetic is better then? Or do you prefer Math::Interval_arithmetic? Is DateTime bad? CamelHump identifiers are actually the community standard for module names. Bad style is not partitioning the name properly into a namespace hierarchy. Caps don’t figure into it. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: New Module Proposal - Math::Interval
Hi Brendan, I think Math::Interval is a fine name. If anyone is looking for a module which handles intervals, they'll find it immediately. The main question you seemed to have about this is: Should I create one module Math::Interval or a hierarchy such as: Math::Interval Math::Interval::Arithmetic Math::Interval::Trigonometric Math::Interval::Logarithmic That seems to be in relation to: This module would contain the basic definition and support functions for intervals. I think it should also include the basic arithmetic operations (+, -, *, /) but I have received the suggestion to break those out into a separate module (Math::Interval::Arithmetic). That would allow other people to add their own extensions. Not having seem your code, I'm at a loss to give you a clear answer, but I can give you a good rule of thumb: so long as you create a good, clear API which will not change (unless labeled alpha, experimental, etc.), don't worry about the module organization as much. Write the code you need and use it. As you use it more, you'll have a better understanding of how things should naturally be decomposed. You can do that yourself or, if enough others are interested, post it to the CPAN and ask for feedback. I'd also strongly recommend that you post this to Perlmonks. There are one or two mathematicians running around there. (Oh, and tell Wren I said hi :) Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: New module: FLV file parsing
A. Pagaltzis writes: * Smylers [EMAIL PROTECTED] [2005-12-02 22:10]: Eric Wilhelm writes: I'm working on CAD::DXF for now, Cad is a well-known acronym. I have no use for anything cad-related in my life at the moment, so I know that I can safely ignore that module. But as it happens, referring to DXF in the context of cad is enough to prompt me into recollecting that .dxf is an AutoCad file extension. Are we reinventing MIME types now? No. Mime media types only apply to file formats; Cpan modules cover much more than that. Let?s just stick with Process::video::x_flv Process::application::x_shockwave_flash Process::image::x_dxf Snip But that's still grouping together all file-format-related modules (under Process::), rather than grouping them by function. It does make sense for CAD::DXF and CAD::Calc to be in the same namespace as each other, and grouping all the file-format modules together prevents that from happening, whether it's the truly awful FF:: or the mostly meaningless Process:: (surely nearly all Cpan modules perform some kind of processing?). DateTime::Format::Mail is a good name for a module; you can see that it is part of the DateTime project and is for processing dates as used in e-mails. Naming it Process::RFC822::DateTime (or similar) is not an improvement. Smylers -- May God bless us with enough foolishness to believe that we can make a difference in this world, so that we can do what others claim cannot be done.
Re: New module: FLV file parsing
Austin Schutz writes: On Fri, Dec 02, 2005 at 04:04:11PM -0600, Chris Dolan wrote: The FF:: namespace is a terrible idea, in my opinion. I expect that it will be meaningless to the majority of module searchers. The argument that search makes names irrelevant is just silly. ..because? There are several places where somebody could first encounter a module name: Ok, I want to do something with my flash file. I search for 'flash file'... Oh look, there's a flash file parser. Do I care what it's called? A large search results listing is one such place. You want to be able to pick out the potentially useful modules from the list, so having their names be as meaningful as possible helps with this. No. I concur that the module name is effectively meaningless, Since FF is meaningless, why bother including it at all? It's just noise. but I don't see that it makes any difference to the searcher. I'm much more likely to spend time investigating modules whose names I can understand. I suspect I'm not alone on that. It's marginally helpful to have a useful name when including it in a module so code doesn't look like $flv = new ASDFsdafs::sjhsdlk, That's a second place module names are encountered, and I'd say that's beyond marginal. Lots of code is read by people other than the original author, and it's good if the approximate use of a module is guessable just from the calling code. but beyond that, what tangible and practical difference does it make? Another place I encounter module names is the RSS feed for Cpan uploads; I'm interested in seeing what sort of things people are making available, and looking out for things that are of interest. There are also feeds for AnnoCpan and Cpan Ratings -- if you see a comment on or a review of a module it's better if you know vaguely what the module is about (or at least if can see what field it's in, so you can dismiss it if it isn't anything of interest to you). People mention modules at PerlMonks, on mailing lists, and in the pub at Perl Mongers meetings and conferences. In all of these places a meaningful name helps everybody identify the module being discussed. Or to put it another way round: if a meaningful name is available, what's the advantage of going out of your way to pick an acknowledged meaningless one? If that were true, the practice of bouncing name ideas off this email list would cease, and I'd just name it FLV.pm. As I understand it there's some rationale for keeping the top level namespace small, so that would probably not be a good choice. Almost. I think that it's cos if you call it FLV it's effectively claiming to be _the_ module for FLV. It's more future proof to call it FLV::Something, anticipating other people contributing FLV::SomethingElse later. Unfortunately there seems to be a meme going round where the advice not to use a single-level name for a module has morphed into not using a multi-level name where the first level is new. I submit these long threads about which module name is better than some other similar name are a waste of time, If you don't care what modules are called then don't participate in them! By definition whatever a module ends up being called you will be satisified! If some of the rest of us (including a modules' author) are fussy it doesn't make module names worse for you ... Smylers -- May God bless us with enough foolishness to believe that we can make a difference in this world, so that we can do what others claim cannot be done.
Re: New module: FLV file parsing
* Smylers [EMAIL PROTECTED] [2005-12-03 09:20]: But that's still grouping together all file-format-related modules (under Process::), rather than grouping them by function. I was not being serious. :-) Regards, -- Aristotle “If you can’t laugh at yourself, you don’t take life seriously enough.”
Re: New module: FLV file parsing
On Sat, Dec 03, 2005 at 08:30:20AM +, Smylers wrote: There are several places where somebody could first encounter a module name: Ok, I want to do something with my flash file. I search for 'flash file'... Oh look, there's a flash file parser. Do I care what it's called? A large search results listing is one such place. You want to be able to pick out the potentially useful modules from the list, so having their names be as meaningful as possible helps with this. If the module description is included the actual name provides some debatable amount of additional benefit. FF:: is a good example. Yes, I agree that it effectively has no meaning, other than an implication that one FF:: module may be related to other FF:: modules. But I disagree that it matters a great deal in the modern CPAN. One wants to parse FLV files, the module description says it does that. It could be FileFormat::FLV, FLV::File, Parser::FLV, Flash::FLV, Video::FLV, etc., and it should make little difference as long as the description is concise, descriptive, and accurate. No. I concur that the module name is effectively meaningless, Since FF is meaningless, why bother including it at all? It's just noise. For two reasons - grouping of related modules under the FF:: heading, and to avoid the top level issue you state below. but I don't see that it makes any difference to the searcher. I'm much more likely to spend time investigating modules whose names I can understand. I suspect I'm not alone on that. It's marginally helpful to have a useful name when including it in a module so code doesn't look like $flv = new ASDFsdafs::sjhsdlk, That's a second place module names are encountered, and I'd say that's beyond marginal. Lots of code is read by people other than the original author, and it's good if the approximate use of a module is guessable just from the calling code. Yes, I agree, but would emphasize approximate. but beyond that, what tangible and practical difference does it make? Another place I encounter module names is the RSS feed for Cpan uploads; I'm interested in seeing what sort of things people are making available, and looking out for things that are of interest. There are also feeds for AnnoCpan and Cpan Ratings -- if you see a comment on or a review of a module it's better if you know vaguely what the module is about (or at least if can see what field it's in, so you can dismiss it if it isn't anything of interest to you). People mention modules at PerlMonks, on mailing lists, and in the pub at Perl Mongers meetings and conferences. In all of these places a meaningful name helps everybody identify the module being discussed. Or to put it another way round: if a meaningful name is available, what's the advantage of going out of your way to pick an acknowledged meaningless one? I have not suggested going out of your way to pick a meaningless one. In this case, the author picked FLV::Info. I don't see how the discussion to change this to something like FileFormat::FLV has made the name so much more intuitive as to have made this list's bandwidth worthwhile. For a given entry (search result, browse page, etc.), the description of the module should be included with the name - again, for example: FLV::Info - Extract metadata from Flash Video files as compared to FileFormat::FLV - Extract metadata from Flash Video files I don't see how these naming adjustments are so much more practical as to warrant the module authors list bandwidth any longer. At one time, when the module list was much smaller and there was no search facility, naming was very important. But with the vast size of the modern CPAN and the addition of searching capabilities, the focus of effort on detailed module naming seems outdated, at least for this particular mailing list. If that were true, the practice of bouncing name ideas off this email list would cease, and I'd just name it FLV.pm. As I understand it there's some rationale for keeping the top level namespace small, so that would probably not be a good choice. Almost. I think that it's cos if you call it FLV it's effectively claiming to be _the_ module for FLV. It's more future proof to call it FLV::Something, anticipating other people contributing FLV::SomethingElse later. Unfortunately there seems to be a meme going round where the advice not to use a single-level name for a module has morphed into not using a multi-level name where the first level is new. Ok, that makes sense. I knew there was a reason. :-) I submit these long threads about which module name is better than some other similar name are a waste of time, If you don't care what modules are called then don't participate in them! By definition whatever a module ends up being called you will be satisified!
Re: New module: FLV file parsing
Austin Schutz writes: On Sat, Dec 03, 2005 at 08:30:20AM +, Smylers wrote: [Austin wrote:] Do I care what it's called? A large search results listing is one such place. You want to be able to pick out the potentially useful modules from the list, so having their names be as meaningful as possible helps with this. If the module description is included the actual name provides some debatable amount of additional benefit. But module names tend to be headings, what draw your attention in first. Yes, descriptions often help to clarify things, but a good name is obviously more useful than a poor one. Sometimes it's hard to find a name that is intuitive, but there doesn't seem to be any point in choosing to 'waste' part of the name on an abbreviation that nobody at all thinks is meaningful. FF:: is a good example. ... it should make little difference as long as the description is concise, descriptive, and accurate. You say If ... above. Not everywhere that mentions a module name has its description next to it (in code, for example). In the same way that it's better to code clearly without comments, than to code obscurely and have to add comments explaining what you mean, it's helpful for module names to be clear even without their descriptions. Since FF is meaningless, why bother including it at all? It's just noise. For two reasons - grouping of related modules under the FF:: heading, But I'm claiming that they _aren't_ related merely by being file formats. The fact that they are file formats isn't the most relevant thing about them. and to avoid the top level issue you state below. Except that I pointed out that this isn't an issue: it's a meme that has been misinterpreted from what the advice on Pause says. There in general isn't a problem with inventing a new top-level namespace for a new category of modules. What's frowned upon is giving a module only a single-level name. So hogging FLV is antisocial, but opening up FLV:: by using FLV::Something is perfectly acceptable, even encouraged. it's good if the approximate use of a module is guessable just from the calling code. Yes, I agree, but would emphasize approximate. Right, so let's try to make module names as meaningful as possible, and not include meaningless bits in them. Or to put it another way round: if a meaningful name is available, what's the advantage of going out of your way to pick an acknowledged meaningless one? I have not suggested going out of your way to pick a meaningless one. I'd claim that renaming FLV::Info to FF:FLV would be -- the module already has one name and changing it would be putting effort in to including the term FF, which everybody agrees is meaningless. I believe the ongoing debates reduce the utility of the module authors mailing list, and therein lies my concern. If there were a separate mailing list dedicated to module naming those concerned with proper names could debate to their satisfaction and allow the authors list to concentrate on other module related issues. Would that be an equitable solution? I wouldn't object to it, but I suspect it isn't worth the hassle of setting it up (and that having 2 lists would just add to the levels of confusion, and people would end up posting the 'wrong' sort of question to each list anyway). This mailing list isn't very high traffic as it is. Nearly all participants are using decent mail or news clients, such that proper threading is preserved. This makes it relatively easy to avoid an entire thread that you're not interested in -- there have been plenty of threads here that I've skipped cos they don't happen to be my kind of thing, but I don't doubt that this is a good place for them to exist. Smylers -- May God bless us with enough foolishness to believe that we can make a difference in this world, so that we can do what others claim cannot be done.
Re: New module: FLV file parsing
# from A. Pagaltzis # on Friday 02 December 2005 02:45 pm: Process::video::x_flv Process::application::x_shockwave_flash Process::image::x_dxf Process::audio::mpeg Process::image::png Process::text::html That's great! Problem solved. Process::application::x_shockwave_flash::FLV::Info Why didn't I think of that earlier? So much easier to type than FF::. --Eric -- But as to modern architecture, let us drop it and let us take modernistic out and shoot it at sunrise. --F.L. Wright --- http://scratchcomputing.com ---
Re: New module: FLV file parsing
On Dec 2, 2005, at 4:20 PM, Austin Schutz wrote: On Fri, Dec 02, 2005 at 04:04:11PM -0600, Chris Dolan wrote: The FF:: namespace is a terrible idea, in my opinion. I expect that it will be meaningless to the majority of module searchers. The argument that search makes names irrelevant is just silly. ..because? Ok, I want to do something with my flash file. I search for 'flash file'... Oh look, there's a flash file parser. Do I care what it's called? No. I concur that the module name is effectively meaningless, but I don't see that it makes any difference to the searcher. Nitpick: FLV is not Flash. FLV is a video format that is often used by Flash movies, but it is not Flash and does not work standalone without a Flash movie to control it. SWF is the file format for Flash movies. It's marginally helpful to have a useful name when including it in a module so code doesn't look like $flv = new ASDFsdafs::sjhsdlk, but beyond that, what tangible and practical difference does it make? You assume that all authors discover modules solely through search.cpan.org? I often discover modules by reading other people's code and seeing what modules they use. If I see use FF::FOOBAR at the top of someone's module, I will have no idea what they are trying to do. But if I see, say FileFormat::Video::FOOBAR then at least I will know the author is trying to interact with a stream of video data. To me, it's as much about readable code as it is about findable modules. If that were true, the practice of bouncing name ideas off this email list would cease, and I'd just name it FLV.pm. As I understand it there's some rationale for keeping the top level namespace small, so that would probably not be a good choice. Beyond that, name it what you will. I submit these long threads about which module name is better than some other similar name are a waste of time, and I do indeed suggest we take them off list as a general rule. Austin I strongly disagree. I think good naming is important for readability and maintainability. Like good variable and method names, module names should be self-documenting whenever feasible. Since module names are harder to change than variable or method names, I say a little forethought and discussion is justified. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Module naming mailing list? Was: Re: New module: FLV file parsing
--- Austin Schutz [EMAIL PROTECTED] wrote: Ok, you and a few other vocal people have very strong opinions about this, which I don't begrudge you. Can we move the discussions to a different list? While I certainly agree that long discussions about how to name modules get tedious after a while, discussions of what modules do and what modules should be named are so intertwined that we'd be forced to bounce back and forth between the lists. The first thing that would happen on a module naming list would be someone asking well, what does your module do? That's often followed by there's already a module which does that or maybe it should do X instead. Then that conversation would legitimately jump back here and would eventually jump to the naming list ... over and over again. That would be even more tedious (hard to believe, I know). Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Module naming mailing list? Was: Re: New module: FLV file parsing
# from Ovid # on Saturday 03 December 2005 12:22 pm: Then that conversation would legitimately jump back here and would eventually jump to the naming list ... over and over again. That would be even more tedious (hard to believe, I know). And eventually everyone in the thread (except the list, because of course the list doesn't want to hear about _foo_) would just be getting CC'd on every message and each thread would become its own little ad-hoc mailing list. Sounds like a plan. --Eric -- If the collapse of the Berlin Wall had taught us anything, it was that socialism alone was not a sustainable economic model. --Robert Young --- http://scratchcomputing.com ---
Re: Module naming mailing list? Was: Re: New module: FLV file parsing
On Sat, Dec 03, 2005 at 12:22:16PM -0800, Ovid wrote: --- Austin Schutz [EMAIL PROTECTED] wrote: Ok, you and a few other vocal people have very strong opinions about this, which I don't begrudge you. Can we move the discussions to a different list? While I certainly agree that long discussions about how to name modules get tedious after a while, discussions of what modules do and what modules should be named are so intertwined that we'd be forced to bounce back and forth between the lists. The first thing that would happen on a module naming list would be someone asking well, what does your module do? That's often followed by there's already a module which does that or maybe it should do X instead. Then that conversation would legitimately jump back here and would eventually jump to the naming list ... over and over again. That would be even more tedious (hard to believe, I know). Yeah, I don't have an answer for this, and with the level of importance some give detailed and debated naming, I guess we're stuck with it. Bring on the nits, let's get splitting. Austin
Re: New module: FLV file parsing
Eric Wilhelm wrote: # from David Nicol # on Wednesday 30 November 2005 02:18 pm: isn't there a multimedia name space? name spaces per-product that is being supported make sense --- Flash::parseFLV perhaps? What else will appear in the Flash:: namespace? Will macromedia release a pure perl version? What all file format parsers and dumpers have in common is that they deal with File Formats. In a lot of cases, the only module that is going to be created is for that format. I'm working on CAD::DXF for now, but would rather name it FF::DXF, similarly with FF::SVG, FF::XAR, FF::PDF, etc. FF::FLV sounds best to me. In about 10 days time, I'm going to forget utterly that FF means File Formats. Does it need to be so terse? Tossing out another suggestion with this in mind: Parse::File::FLV David -- It's overkill of course, but you can never have too much overkill.
Re: New module: FLV file parsing
On 12/2/05, David Landgren [EMAIL PROTECTED] wrote: Eric Wilhelm wrote: What else will appear in the Flash:: namespace? Will macromedia release a pure perl version? In about 10 days time, I'm going to forget utterly that FF means File Formats. Does it need to be so terse? Tossing out another suggestion with this in mind: Parse::File::FLV The flood of modules that also pertain to manipulating flash files, now that Pagaltzis has smashed the levy. God only knows what they might look like. Flash::import::gif::animated, Flash::import::pdf, Flash::Dancer. -- David L Nicol Which is better, to burn out or to fade away? Refer to authorities from classical Roman, Greek and Chinese thought in your answer.
Re: New module: FLV file parsing
Eric Wilhelm writes: # from David Nicol # on Wednesday 30 November 2005 02:18 pm: isn't there a multimedia name space? ame spaces per-product that is being supported make sense --- Flash::parseFLV perhaps? What else will appear in the Flash:: namespace? It doesn't matter if nothing else appears there -- the module would still have a name that's readily understandable. What all file format parsers and dumpers have in common is that they deal with File Formats. Yes, but that isn't more relevant than the particular file format each deals with. For example, I'd be much more likely to first think that I'd be working with Flash files, and then realize that I need to parse them, than to start by thinking that I'm working with files that have a format, and only then that the format is Flash. In a lot of cases, the only module that is going to be created is for that format. And that causes what harm? I'm working on CAD::DXF for now, Cad is a well-known acronym. I have no use for anything cad-related in my life at the moment, so I know that I can safely ignore that module. But as it happens, referring to DXF in the context of cad is enough to prompt me into recollecting that .dxf is an AutoCad file extension. but would rather name it FF::DXF, Whereas if I saw that I wouldn't know what either set of letters mean; DXF is sufficiently meaningful in my brain to make me think of AutoCad without any context. And FF could be one of many things: recently I've seen it used to abbreviate Firefox in quite a few places; if I'd just been reading some music (or trying to solve a crossword) I might think of it meaning very loud. similarly with FF::SVG, FF::XAR, FF::PDF, etc. What does that achieve? Putting all the cad-related modules makes good sense to me, and similarly for other things. FF::FLV sounds best to me. I wouldn't have a clue what that means. I hadn't heard of FLV before this thread, and I wouldn't guess FF without this thread either. With Flash::FLV I still wouldn't know what FLV stands for, but I'd have a clue as to its context -- enough of a clue to know whether I'm interested in investigating the module further if it I see it in the 'recent uploads' list. Smylers -- May God bless us with enough foolishness to believe that we can make a difference in this world, so that we can do what others claim cannot be done.
Re: New module: FLV file parsing
On Fri, Dec 02, 2005 at 04:04:11PM -0600, Chris Dolan wrote: So, I already published it as FLV::Info, but this discussion has convinced me that FileFormat::FLV is the best option. I may use that name for v0.02. My only hesitation is that nobody else seems to be using that top-level namespace at this time. The FF:: namespace is a terrible idea, in my opinion. I expect that it will be meaningless to the majority of module searchers. The argument that search makes names irrelevant is just silly. ..because? Ok, I want to do something with my flash file. I search for 'flash file'... Oh look, there's a flash file parser. Do I care what it's called? No. I concur that the module name is effectively meaningless, but I don't see that it makes any difference to the searcher. It's marginally helpful to have a useful name when including it in a module so code doesn't look like $flv = new ASDFsdafs::sjhsdlk, but beyond that, what tangible and practical difference does it make? If that were true, the practice of bouncing name ideas off this email list would cease, and I'd just name it FLV.pm. As I understand it there's some rationale for keeping the top level namespace small, so that would probably not be a good choice. Beyond that, name it what you will. I submit these long threads about which module name is better than some other similar name are a waste of time, and I do indeed suggest we take them off list as a general rule. Austin
Re: New module: FLV file parsing
Chris Dolan writes: So, I already published it as FLV::Info, but this discussion has convinced me that FileFormat::FLV is the best option. I still don't see what's to be gained from having all modules that deal with specific file-formats grouped together -- or more specifically why that makes more sense than grouping them in Cad:: or Graphics:: or Spreadsheet:: or whatever else they are actually useful for. The FF:: namespace is a terrible idea, in my opinion. Ditto. I expect that it will be meaningless to the majority of module searchers. Exactly -- even if you search by FLV, seeing FF::FLV in the results list doesn't help you at all. As for the Flash:: namespace, I don't think that's best. While FLV is primarily used in the Macromedia Flash Player ... However it's preferable for module names to be 'best fit' rather than 'pedantically accurate'. We want something that's meaningful to most people, even if technically it does more than that. ... it is not Flash but is a standalone video format. Well how about Video::FLV or Video::Format::FLV then? (Or even Video::Flash::FLV?) That would be like naming a CSS parsing module HTML::CSS::Parser, Yes, and I wouldn't object to that -- especially if CSS were a much less-well-known technology, such as when CSS clearly has utility beyond just HTML, despite its dominant usage. Yeah, but dominant usage is a great way of finding something. Anybody who wants to use CSS for something else is bound to know that HTML is its dominant usage. CSS has recently been used to format a book using Yes Logic's Prince ... but HTML was still used for the mark-up. Smylers -- May God bless us with enough foolishness to believe that we can make a difference in this world, so that we can do what others claim cannot be done.
Re: New module: FLV file parsing
* Eric Wilhelm [EMAIL PROTECTED] [2005-12-02 00:20]: What all file format parsers and dumpers have in common is that they deal with File Formats. In a lot of cases, the only module that is going to be created is for that format. I'm working on CAD::DXF for now, but would rather name it FF::DXF, similarly with FF::SVG, FF::XAR, FF::PDF, etc. I thought you were using “FF” as a shorthand for FileFormat on which I had no particular opinion, but following discussion indicates you actually proposed a literal “FF“ TLNS. In that case, I am strongly -1. It’s opaque without explaination, and even if you know what it means, you can’t meaningfully search on it. Both are terrible properties for a name. Regards, -- Aristotle “Like punning, programming is a play on words.” – Alan J. Perlis, “Epigrams in Programming”
Re: New module: FLV file parsing
* Smylers [EMAIL PROTECTED] [2005-12-02 22:10]:
Eric Wilhelm writes:
I'm working on CAD::DXF for now,
Cad is a well-known acronym. I have no use for anything
cad-related in my life at the moment, so I know that I can
safely ignore that module. But as it happens, referring to DXF
in the context of cad is enough to prompt me into recollecting
that .dxf is an AutoCad file extension.
Are we reinventing MIME types now? Let’s just stick with
Process::video::x_flv
Process::application::x_shockwave_flash
Process::image::x_dxf
Process::audio::mpeg
Process::image::png
Process::text::html
...
please.
Regards,
--
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Searching and Browing (was: Re: New module: FLV file parsing)
Austin Schutz wrote: On Fri, Dec 02, 2005 at 04:04:11PM -0600, Chris Dolan wrote: So, I already published it as FLV::Info, but this discussion has convinced me that FileFormat::FLV is the best option. I may use that name for v0.02. My only hesitation is that nobody else seems to be using that top-level namespace at this time. The FF:: namespace is a terrible idea, in my opinion. I expect that it will be meaningless to the majority of module searchers. The argument that search makes names irrelevant is just silly. ..because? Ok, I want to do something with my flash file. I search for 'flash file'... Oh look, there's a flash file parser. Do I care what it's called? No. I concur that the module name is effectively meaningless, but I don't see that it makes any difference to the searcher. Two bad assumptions here: 1) the searcher always knows what words to search for, and 2) searching is an acceptable substitute for browsing. In this case of course, 'flash' is pretty obvious and searching for it should give one everything on CPAN, but in other cases this might not be true. For example, I had a little trouble with the RSS and Atom distinction, and had I been even more ignorant, I might have missed some useful modules. Taking the other side of the coin, browsing is much more useful when the module has a name that can catch the eye. Right now we only have two 'browsing' modes in CPAN, the Recent Arrivals list, and the all-but-useless Module List Chapter. I'd like to see true browsing, arranged in a tree structure (e.g., a list of top level names that one could click on, which would bring up a list of the TopLevelName::NextLevelNames, and so on). Granted that I'm using a non-existent feature [1] to demonstrate a point, but just how useful would an FF top level name be in this situation? It's marginally helpful to have a useful name when including it in a module so code doesn't look like $flv = new ASDFsdafs::sjhsdlk, but beyond that, what tangible and practical difference does it make? Choosing meaningful variable names in your code is considered good programming practice. Why wouldn't it be an equally good practice for naming modules? -john [1] In theory, this means that I just volunteered to work on this. Given that, does this idea interest anyone?
Re: New module: FLV file parsing
Hi Chris,
I’ll make the assumption that whoever is going to look for the
module is most likely to simply query search.cpan.org for “FLV”.
On that basis, how descriptive are the ideas?
* Chris Dolan [EMAIL PROTECTED] [2005-11-30 16:10]:
So, is FLV::Info fine?
That sounds okay.
Or File::FLV? Or File::FLV::Parser?
I don’t think File:: is right for this.
In any case, File::FLV says nothing particular about the module.
Instead of File::FLV::Parser I’d suggest Parse::FLV. But putting
it under Parse:: means you’ll have to put modules in disparate
TLNSes if you ever write a module that supports things other than
parsing the format. If you actually plan to use the same codebase
for a family of modules that include support for manipulating as
well as parsing such files, that would be a silly choice.
Or Video::FLV?
Sounds forced to me. The module doesn’t have to do much with
video per se, other than that the file format it parses is a
container for video data. So in essence, to the searcher, the
Video:: part is redundant.
Bottom line, it’s probably best to stick it in FLV::Info and call
it a day.
Regards,
--
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: New module: FLV file parsing
# from A. Pagaltzis # on Wednesday 30 November 2005 07:49 am: Or File::FLV? Or File::FLV::Parser? I don’t think File:: is right for this. Right, because it's not a filehandle or otherwise IO/filesystem related. Should we be using an FF:: namespace for File Formats? I've got a few modules that would like to live there too. --Eric -- Time flies like an arrow, but fruit flies like a banana. --Groucho Marx --- http://scratchcomputing.com ---
Re: New module: FLV file parsing
isn't there a multimedia name space? name spaces per-product that is being supported make sense --- Flash::parseFLV perhaps? Or File::FLV? Or File::FLV::Parser? I don't think File:: is right for this. Right, because it's not a filehandle or otherwise IO/filesystem related. -- David L Nicol Which is better, to burn out or to fade away? Refer to authorities from classical Roman, Greek and Chinese thought in your answer.
Re: new module IO::Mail
# The following was supposedly scribed by
# Eric Wilhelm
# on Monday 21 March 2005 06:02 pm:
The code is in my subversion repository, synopsis below for
convenience.
http://ericwilhelm.homeip.net/svn/File-Backup-Config/trunk/code/perl/
lib/IO/Mail.pm
Wow. Ditching the tied filehandle and switching to open($handle, '',
\$scalar) does wonders for my sanity.
http://ericwilhelm.homeip.net/svn/File-Backup-Config/branches/IO-Mail-scalar-branch/code/perl/lib/IO/
Haven't tried to go back to the destructor-based send process. I ran
into trouble with IPC::Run because I hadn't implemented the full
interface for the tied handles. Anyway, the object wasn't really a
tied handle. Rather, the point was to make writing mail as simple as
printing to the console. So, for instance you might have this
construct.
my $mail;
if($mailto) {
$mail = IO::Mail-output();
$mail-headers(
To = $mailto,
Subject = incoming files,
);
}
...
print $num files in $time seconds\n;
...
$mail and ($mail-send());
--Eric
--
Politics is not a bad profession. If you succeed there are many
rewards, if you disgrace yourself you can always write a book.
-- Ronald Reagan
-
http://scratchcomputing.com
-
Re: New module: Regexp::Trie
On Wed, Jul 14, 2004 at 11:08:20PM +, Smylers wrote: The docs that come with Perl seem to use regexp in the most official-looking places (section heading in perlop) and the warning classification is also spelt that way. There are 688 modules with Regex in their name, and 582 with Regexp, so I don't think a clear consensus has emerged. :) Restricting the search just to module names gives the much more plausible numbers of 128 for Regex and 81 for Regexp. Given that the former necessarily include the latter, that's actually a ratio of 81:46 in favour of Regex, for what it's worth. More to the point, a good reason to use Regexp is that it turns up in search results for either spelling, so by choosing the longer version you aren't relying on others to remember whether it's got that p in it or not. $ perl -le 'print ref qr//' Regexp -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: New Module: Time::Seconds::GroupedBy
At 06:00 AM 2004-07-14, Bruno Negrão wrote: Hi Sean, i coudn't get what you mean (it is too colloquial for my poor english understanding...) What do you mean? Should i keep on this project or give it up? Oops, sorry. I think you should go ahead with your project. -- Sean M. Burkehttp://search.cpan.org/~sburke/
Re: new module: Time::Seconds::GroupedBy
* Dave Rolsky [EMAIL PROTECTED] [2004-07-14 03:25]: Ah, so you reinvented DateTime::Format::Duration. Actually, I think he reinvented Time::Seconds, which is part of the Time::Piece distro. Well, both, I guess. Goes to show how many, *many* people have written this sort of thing before in various forms and shapes. Regards, -- Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: new module: Time::Seconds::GroupedBy
Actually, I think he reinvented Time::Seconds, which is part of the Time::Piece distro. No guys, Time::Seconds doesn't give the same answer my module does. Time::Seconds converts seconds entirely in minutes or hours or days or etc. For example, it says that 7341 seconds are: 2,03916 hours 122,35 minutes 0,08 days etc. I really Think i should extend Time::Seconds instead of publishing a new module, but i couldn´t contatc the authors of that module. Time::Duration addresses the same calculation i'm doing, but the way it gives the answer is not that good. i think i'gonna talk with DateTime group a litle bit, they are more inserted in this context. thank you all, bruno negrao.
Re: New Module: Time::Seconds::GroupedBy
Enh, sorta. Most of the work of Time::Duration is figuring out how to whittle down a multiple-units expression of a time to a particular degree of concision. It also doesn't have the concept of month. You're probably better off just starting over, since stuff like $mins = int($secs) / 60; $secs -= $mins * 60; is neither complex nor error-prone. Hi Sean, i coudn't get what you mean (it is too colloquial for my poor english understanding...) What do you mean? Should i keep on this project or give it up? bruno.
Re: new module: Time::Seconds::GroupedBy
On Tue, Jul 13, 2004 at 09:01:30PM -0300, Bruno Negr?o wrote: Ah, so you reinvented DateTime::Format::Duration. use DateTime::Format::Duration; my $fmt = DateTime::Format::Duration-new( pattern = '%H hours, %M minutes, %S seconds', normalize = 1, ); print $fmt-format_duration_from_deltas( seconds = 7341, ), \n; Oh, what a sadness. Indeed i never saw the DateTime project before. But still my module is far easier to use than DateTime::Format::Duration. Do you believe it is worth to publish it in Time::Seconds::GroupBy? I would rather see more standardization on the use of the DateTime project, in much the same way that people think of DBI when they think of accessing databases through Perl. In this case, perhaps some clear documentation and examples (just like the one above) would be the best solution. I think if such a solution was easy to find on Google and clearly documented, people would use it, especially once there is more awareness of DateTime as a comprehensive date time solution for Perl. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: new module: Time::Seconds::GroupedBy
I would rather see more standardization on the use of the DateTime project, in much the same way that people think of DBI when they think of accessing databases through Perl. In this case, perhaps some clear documentation and examples (just like the one above) would be the best solution. I think if such a solution was easy to find on Google and clearly documented, people would use it, especially once there is more awareness of DateTime as a comprehensive date time solution for Perl. I agree Mark, i've posted my module on the DateTime mailing list. Let's see what they say about it. But i think the DateTime project is not gaining fair promotion once their modules are not even appearing on the main Module List in the cpan's site at http://www.cpan.org/modules/00modlist.long.html. If people should concentrate effort in making this framework the solution for Dates and times related problems, the DateTime namespace should at least appear on the Module List, right? Regards, bruno.
Re: new module: Time::Seconds::GroupedBy
On Wed, 14 Jul 2004, Bruno Negrão wrote: I would rather see more standardization on the use of the DateTime project, in much the same way that people think of DBI when they think of accessing databases through Perl. In this case, perhaps some clear documentation and examples (just like the one above) would be the best solution. I think if such a solution was easy to find on Google and clearly documented, people would use it, especially once there is more awareness of DateTime as a comprehensive date time solution for Perl. I agree Mark, i've posted my module on the DateTime mailing list. Let's see what they say about it. But i think the DateTime project is not gaining fair promotion once their modules are not even appearing on the main Module List in the cpan's site at http://www.cpan.org/modules/00modlist.long.html. Some of them are, but not all. Frankly, I don't think most people really look at the list much, nor do most people consider it authoritative. What'd help more would be some articles on the project. I've been wanting to write one for a while, but I'm always short on time. If people should concentrate effort in making this framework the solution for Dates and times related problems, the DateTime namespace should at least appear on the Module List, right? Some of them _are_ registered, but that document you're referring to hasn't been regenerated since 2002/08/27! I wish the CPAN folks would just remove it if it won't be generated regularly. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: new module: Time::Seconds::GroupedBy
* Dave Rolsky [EMAIL PROTECTED] [2004-07-14 19:26]: Some of them _are_ registered, but that document you're referring to hasn't been regenerated since 2002/08/27! I wish the CPAN folks would just remove it if it won't be generated regularly. Does anyone else here think that the list should probably just be done away with entirely? Regards, -- Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: new module: Time::Seconds::GroupedBy
On Wed, 14 Jul 2004, A. Pagaltzis wrote: * Dave Rolsky [EMAIL PROTECTED] [2004-07-14 19:26]: Some of them _are_ registered, but that document you're referring to hasn't been regenerated since 2002/08/27! I wish the CPAN folks would just remove it if it won't be generated regularly. Does anyone else here think that the list should probably just be done away with entirely? Given the fact that most authors seem to not register their stuff, the [EMAIL PROTECTED] list is slow as heck, and that the web pages never get regenerated, yes. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: new module: Time::Seconds::GroupedBy
* Dave Rolsky [EMAIL PROTECTED] [2004-07-14 19:41]: Does anyone else here think that the list should probably just be done away with entirely? Given the fact that most authors seem to not register their stuff, the [EMAIL PROTECTED] list is slow as heck, and that the web pages never get regenerated, yes. Now the question is: how would we make that happen? Regards, -- Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: New module: Regexp::Trie
Sounds like cool stuff!
David Landgren [EMAIL PROTECTED] writes:
[...]
2. Is Regexp::Trie a good name? (I fall into the regexp is spelt with
a p camp, but if Regex is preferred that's fine by me. I can never
remember which, if either, is deprecated).
There are 688 modules with Regex in their name, and 582 with Regexp,
so I don't think a clear consensus has emerged. :)
I personally think ::Trie is a bit technical; a user who needs this
module isn't likely to search for 'Trie', or find this by browsing
among the other 582 modules with Regexp in their name. I would think
Regexp::Optimize{,r,d} would be better names, but that's just MHO.
3. Is the lexer namespace a good idea? Or is there a better way do to
this? I'm open to any design suggestions on this issue since nothing
is written yet.
shrug It depends on whether you foresee a large number of Lex
modules being required, or updating the Lex portions of your module
independently of the Regexp::Trie portions. If either of these seem
likely, it's a good idea; otherwise it's just an implementation
decision.
-ScottG.
Re: New module: Regexp::Trie
On 7/14/2004 5:29 PM, David Landgren wrote: Hello, I gave a talk at the French Perl Workshop in June about some work I was doing to produce really large (i.e. length($re) 5) regular expressions for Postfix access maps. (Postfix can be compiled with the PCRE library). A number of people expressed interest in the approach and wondered if and when it would be available as a module on CPAN. The idea is that sometimes you have a large set of regular expressions (e.g. 2000), and you want to test whether a string matches any of them. You don't particularly care *which* expression matches, the fact that one matches is sufficient. Brute forcing it with a loop is not very efficient. Concatenating them with | is not efficient either, if a large subset of the expressions share a common prefix. I know about Jarkko's Regex::PreSuf and another module whose name escapes me this instant, but they both suffer from the limitation of not being metacharacter-aware. For instance: use Regex::PreSuf; print presuf(qw(a\d+foo a\D+123)); produces: a\\(?:D\+123|d\+foo) The module I'm developing works with variable length tokens, and thus deals with the above correctly: use Regexp::Trie; my $rt = Regexp::Trie-new; $rt-add( qw/a \\d+ f o o/ ); $rt-add( qw/a \\D+ 1 2 3/ ); print $rt-re; produces: a(?:\D+123|\d+foo) (modulo me getting the backslashes escaped correctly here -- the algorithm does the right thing). The above example contains (IMO) too much make-work code, so I'm planning on distributing a number of helper packages as well, which will take care of the general cases. I'm thinking of something like my $rt = Regexp::Trie-new( Regexp::Trie::Lex::simple(qw( a\\d+foo a \\D+123 )) ); print $rt-re; I.e., the Regexp::Trie::Lex::* namespace, whose packages simply have to return an object that contains an 'add' method. The Regexp::Trie::new constructor will simply take the returned object and call its 'add' method until exhaustion, and fill up its own internal structure. As another example, I have a set of regexps that should never contain a bare . (dot) metachar. To do so is an error. Writing a seperate lexer package for this allows such error-checking to take place. I spoke with Nicholas Clark about the item in the latest perltodo, specifically: quote =head2 common suffices/prefices in regexps (trie optimization) Currently, the user has to optimize Cfoo|far and Cfoo|goo into Cf(?:oo|ar) and C[fg]oo by hand; this could be done automatically. /quote This is apparently a non-trivial undertaking to do in core and he suggested I pursue the release of this module regardless (I'm targetting 5.005_03 as a baseline anyway). If I haven't put you to sleep by now, I have the following questions: 1. Has this been done before (i.e. shoot me now and put me out of my misery). I haven't seen anything, but I haven't really looked either. I do see it as being a usefull module though. 2. Is Regexp::Trie a good name? (I fall into the regexp is spelt with a p camp, but if Regex is preferred that's fine by me. I can never remember which, if either, is deprecated). Definately in the Regexp::* namespace. Trie? 3. Is the lexer namespace a good idea? Or is there a better way do to this? I'm open to any design suggestions on this issue since nothing is written yet. What about Japhy's new Regexp::Parser ? Thanks for reading this far, David Landgren
Re: New module: Regexp::Trie
Randy W. Sims wrote: [...] 3. Is the lexer namespace a good idea? Or is there a better way do to this? I'm open to any design suggestions on this issue since nothing is written yet. What about Japhy's new Regexp::Parser ? Hmm. Yes, I've know about it, and even downloaded it to play with it this weekend. But wrote tests instead :) I'm not sure how fine-grained it is, and/or how much fine-grainedness I need. For instance, given '(?:foo|bar| (?:cat|dog))', I don't care about isolating the (?:cat|dog) part. It's up to you to feed it the tokens at the granularity you want to deal with. Thanks for the pointer. David
Re: New module: Regexp::Trie
* David Landgren [EMAIL PROTECTED] [2004-07-14 23:30]: 1. Has this been done before (i.e. shoot me now and put me out of my misery). I haven't particularly looked for such a thing, but nor have I heard of it. And I've been around mentions of ::PreSuf so often that I think it reasonable to believe I would have seen a side note about such a thing somewhere. 2. Is Regexp::Trie a good name? (I fall into the regexp is spelt with a p camp, but if Regex is preferred that's fine by me. I can never remember which, if either, is deprecated). The big name modules are all in Regexp::. AFAIK the story is that noone really likes regexp, but it became the official namespace long ago and now holds that position. 3. Is the lexer namespace a good idea? Or is there a better way do to this? I'm open to any design suggestions on this issue since nothing is written yet. I'm not sure a separately visible lexer is even necessary. Does the regex syntax change that often? Is it useful to expose the lexer output? I think the answers are no and maybe, so I can't say. Regards, -- Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: New module: Regexp::Trie
On Jul 14, David Landgren said: Randy W. Sims wrote: What about Japhy's new Regexp::Parser ? Hmm. Yes, I've know about it, and even downloaded it to play with it this weekend. But wrote tests instead :) I uploaded v0.10 the other day. It's got a much better hierarchy system (read: one that works). You might be able to just make your module a subclass that returns the optimized form on -visual or -qr. -- Jeff japhy Pinyan % How can we ever be the sold short or RPI Acacia Brother #734 % the cheated, we who for every service http://japhy.perlmonk.org/ % have long ago been overpaid? http://www.perlmonks.org/ %-- Meister Eckhart
Re: new module: Time::Seconds::GroupedBy
Is there any reason to use it in preference to DateTime::Duration?
Hi Aristotle,
My module differs from DateTime::Duration because it is not dealing with dates. It
does not try to foresee which is a future of past
date based in a bunch of seconds.
It just provide a means to calculate a time quantity that is more human readable
than a big number of seconds.
For example, if you're making a big file transfer over the network everyday, and this
transfer takes 7341 seconds to finish, and you
want to receive a report saying how much time the transfer took, indeed, you want to
know that the file transfer took 2 hours, 2
minutes and 21 seconds (7341 seconds grouped by hours).
My module will calculate this conversion of seconds to a bigger time group, HOURS,
in this case.
To do this with my module you would:
# - converting seconds to hours -
new $time = new Time::Seconds::GroupedBy('HOURS');
my ($secs, $mins, $hours) = $time-calculate(7341);
print $hours hours $mins minutes $secs seconds\n;
So, if you have more seconds to calculate, maybe hours is a small quantity, then you
may chose to group seconds in a bigger group,
like DAYS. For example, to know that 734100 seconds are equivalent to 8 days, 11
hours, 55 mins, 0 seconds.
# - converting seconds to days -
$time-groubBy('DAYS');
my ($secs, $mins, $hours, $days) = $time-calculate(734100);
When DAYS is a small group, you could group them by MONTHS, ultimately, by YEARS.
Well, it's usefull for me. I didn't find yet a module providing this kind of
conversion...
what do you think?
A hug,
bruno.
Re: new module: Time::Seconds::GroupedBy
* Bruno Negrão [EMAIL PROTECTED] [2004-07-13 23:53]:
Hi Aristotle,
My module differs from DateTime::Duration because it is not
dealing with dates. It does not try to foresee which is a
future of past date based in a bunch of seconds.
It just provide a means to calculate a time quantity that is
more human readable than a big number of seconds.
You mean, it deals with a... duration?
To do this with my module you would:
# - converting seconds to hours -
new $time = new Time::Seconds::GroupedBy('HOURS');
my ($secs, $mins, $hours) = $time-calculate(7341);
print $hours hours $mins minutes $secs seconds\n;
Ah, so you reinvented DateTime::Format::Duration.
use DateTime::Format::Duration;
my $fmt = DateTime::Format::Duration-new(
pattern = '%H hours, %M minutes, %S seconds',
normalize = 1,
);
print $fmt-format_duration_from_deltas(
seconds = 7341,
), \n;
Well, it's usefull for me. I didn't find yet a module providing
this kind of conversion...
I haven't done this before either. It took me about 10 minutes of
research on CPAN. Maybe my advantage was that I knew about the
DateTime project which set out to solve the issue of using Perl
for date and time math Once And For All.
Regards,
--
Aristotle
If you can't laugh at yourself, you don't take life seriously enough.
Re: new module: Time::Seconds::GroupedBy
Hm It just provide a means to calculate a time quantity that is more human readable than a big number of seconds. You mean, it deals with a... duration? Can I call it time quantity?! ;-) Ah, so you reinvented DateTime::Format::Duration. use DateTime::Format::Duration; my $fmt = DateTime::Format::Duration-new( pattern = '%H hours, %M minutes, %S seconds', normalize = 1, ); print $fmt-format_duration_from_deltas( seconds = 7341, ), \n; Oh, what a sadness. Indeed i never saw the DateTime project before. But still my module is far easier to use than DateTime::Format::Duration. Do you believe it is worth to publish it in Time::Seconds::GroupBy? bruno.
