Re: name for a module that implements dynamic inheritance?
On Friday, October 31, 2003, at 01:34 PM, A. Pagaltzis wrote: The problem with fancy names is they make hard if not impossible for people to find what they're looking for. See Jarkko's "Zen of Comprehensive Archive Networks" at http://use.perl.org/article.pl?sid=02/11/12/1616209 Or, for the canonical version: http://www.cpan.org/misc/ZCAN.html Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://www.kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
Version Numbers
Hi All, What's the consensus on the version numbers to give to different modules in a CPAN distribution? I've traditionally only incremented the main module in a distribution and any modules that have been changed since the last release. But this means that I have modules in a single distribution with different version numbers. Other CPAN authors have omitted version numbers from all but the module that names the distribution. Still others have made all of the modules in a single distribution have the same version number. So, what do people like or prefer, and why? Is there a consensus on this? If so, what is it? Thanks, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://www.kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
Re: Version Numbers
On Jan 8, 2004, at 7:46 PM, David Wheeler wrote:
What's the consensus on the version numbers to give to different
modules in a CPAN distribution?
Thank you all for your great feedback. I personally have always
considered it important for all modules in a distribution to have
version numbers, though not necessarily the same one. To me, it makes
sense that they have separate numbers, because they don't necessarily
change when the main module changes.
The only disadvantage to this approach is the circumstance in which,
for example, someone uses the version number in their requirements of a
module in your distribution that's not the main module. If the
secondary module doesn't change but the primary one does, it might make
a difference. But probably not. I think this would be a rare
circumstance.
For the Bricolage project, I use CVS revision numbers for my module
numbers, like Andy does. Andy's syntax is this:
$VERSION = sprintf("%d.%02d", q$Revision: 1.23$ =~ /(\d+)\.(\d+)/);
The disadvantage to his approach, however, is that it only works if you
never branch. Otherwise, your modules could change, but the version
number wouldn't change, because only the first two numbers make it into
the module. So if the version number is 1.3.20, and then you change the
module and the version increments to 1.3.21, the version number would
still be 1.03.
It also won't work if your subversion numbers get to be over 100. So if
the Revision is 1.145, the version would be 1.14, which wouldn't work,
since version 1.14 was released ages ago. For Bricolage, we use this
syntax, instead:
our $VERSION = (qw$Revision: 1.63 $ )[-1];
This captures the entire Revision number. For Bricolage 2.0, we're
actually going to use John Peacock's version module, instead:
our $VERSION = version->new(qw$Revision: 1.7 $);
Now, all that said, I think I'll continue to just use independent, but
manual, version numbers for my CPAN modules. This is because most of
them don't have too many modules, and only a few of them will change
between releases. For bigger projects, I'll go with the CVS Revision
number solution.
I do like Aristotle's idea of providing a line in the POD that says
what version of the distribution a module came with. Guess I'll start
working on a module that does the following:
* Updates the distribution number line in POD.
* Validates that the main module, README and Changes have the same
version number.
Yeah, right...in my spare time!
Thanks again for all your thoughts! You all have confirmed that what
I've been doing may be considered a best practice -- or among the
acknowledged best practices!
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://www.kineticode.com/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Kineticode. Setting knowledge in motion.[sm]
Re: Version Numbers
On Jan 9, 2004, at 6:08 PM, A. Pagaltzis wrote: You should probably look at Liz' Devel::Required module first, even though it doesn't yet(!) do what you've sketched -- and particularly because: Yeah, right...in my spare time! :-) Yeah, but I use Module::Build, not ExtUtils::MakeMaker. But maybe I can pilfer some code. A patch is probably a better investment of your time than a from-scratch attempt. See above. Cheers, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://www.kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
Re: Version Numbers
On Jan 10, 2004, at 2:01 AM, Elizabeth Mattijsen wrote: I don't think support for it should be that difficult: it all depends on knowing what sub to steal from Module::Build and what to do with which of its parameters. The example of WriteMakefile should be clear, I think ;-) For Module::Build, it's not necessary to steal a function; you can subclass Module::Build, instead. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://www.kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
Re: CVS version module name
On Feb 4, 2004, at 2:14 PM, David Robins wrote: I'm looking for suggestions for a name for a module that allows use of CVS revisions as perl versions (or for the name of an existing one, but I've searched CPAN and perlmonks and didn't find one). It works like: It's called "version". http://search.cpan.org/dist/version/ It allows this syntax: our $VERSION = version->new(qw$Revision: 1.10 $); Regards, David
Re: CVS version module name
On Feb 4, 2004, at 2:34 PM, David Robins wrote: It's called "version". http://search.cpan.org/dist/version/ It allows this syntax: our $VERSION = version->new(qw$Revision: 1.10 $); And it doesn't work for the comparisons. It'll import a CVS tag, but it still thinks 1.2 > 1.10. No, it doesn't: % perl -Mversion -le 'print version->new(qw$ Revision 1.2$) > version->new(qw$ Revision 1.10$)' % perl -Mversion -le 'print version->new(qw$ Revision 1.10$) > version->new(qw$ Revision 1.2$)' 1 Regards, David
Re: CVS version module name
On Feb 4, 2004, at 2:59 PM, David Robins wrote: Ah, yes, that's right, the issue was that it converts it into a fairly horrible "%.03" representation which requires me to change the use to e.g. 'use 1.002' for 1.2 and 1.02 or 1.020 for 1.20, which I don't like very much. You have to do that with Perl versions, anyway: use 5.008; And since this is likely to be the way versions are supported in Perl 5.10, it's worthwhile to get used to it now. I don't really like trying 'use qw($Revision 1.20$)' either, even if that works. I think it'd actually be use My::Module 1.020; Or use My::Module version->new(1.2); But I'm not sure. John will be able to tell you. But coordinating with the 'version' author might be a good way to go, as David Ralsky suggested; I'll look into it. Yes, excellent idea. John has thought a lot about this stuff... Regards, David
Re: Testing output to STDOUT and STDERR
On Feb 8, 2004, at 5:52 PM, Adriano R. Ferreira wrote: If it is worthy, there's a bunch of things I would appreciate some feedback on: * does it make sense the use of 'seize' and 'release' as above (I am not an English native speaker and I am not sure). I like them. They're quirky. * What would be a sensible name: IO::Seize, Test::Stdout? The latter, I think. * It is necessary that I understand better the interaction of the code being tested and how Test:: modules and Test::Harness works If you're tie'ing off STDOUT and STDERR, it should be fine. * It would be better to make it a real Test:: module? Perhaps: stdout_is(print STDOUT "hello", "hello", 'print "hello" to STDOUT'); You might want to look at the TieOut module that comes with ExtUtils::MakeMaker. I myself have a version of it in the App::Info distribution, in t/lib: http://search.cpan.org/src/DWHEELER/App-Info-0.25/t/lib/TieOut.pm Regards, David
Re: NAME field
On Apr 1, 2004, at 2:25 AM, Hans Oesterholt-Dijkema wrote: CPAN displays the description from the 'NAME' pod field from Conf-0.06. However it doesn't display the ones from Conf-SQL and Conf-INI. (see http://search.cpan.org/~oesterhol/). What can I do to let it display this information? It looks like they're there to me. David
Re: Possibly stupid question...
On May 24, 2004, at 11:32 AM, Hugh S. Myers wrote: After uploading a new version of one of my modules, I noticed that I had forgotten to change the version number in the readme to match the new version number. The more anal-retentive side of my nature cries out to fix this flaw---so the question is, is there a way short of yet another version, to repair this situation? Thanks! No, because pause does not allow you to upload a file with exactly the same name as any other file that has ever been uploaded. So unless you don't include the version number in your file name (you should!) or you include the date (don't do that!), then you'll have to release a new version with the version number incremented and properly updated in your README. HTH, David
Re: ANNOUNCE: WWW::Map 0.01
On Jul 9, 2004, at 1:23 PM, A. Pagaltzis wrote: So, I'd propose something like ::MapService instead. I think that conjures up the right image immediately. Or ::MapLink. Regards, David
Re: ANNOUNCE: WWW::Map 0.01
On Jul 9, 2004, at 3:43 PM, Dave Rolsky wrote: This'd be great _except_ that www.maplink.com is the website for a map/travel book company. Too confusing. WWW::MapLinker? D
Re: ANNOUNCE: WWW::Map 0.01
On Jul 9, 2004, at 8:46 PM, Dave Rolsky wrote: WWW::MapLinker? That implies that it's a module that performs an action (linking), as opposed to a module that is something (a link). WWW::MapLink, then. David
Re: [Module::Build] requires_one_of
Moving the conversation over to module-authors...
On Jul 16, 2004, at 11:52 AM, Randy W. Sims wrote:
David Wheeler wrote:
On Jul 9, 2004, at 3:00 PM, David Wheeler wrote:
Yes, but what about applications that require one among a list of
modules? I'm thinking of things like DBIx::SearchBuilder, which
requires one of several DBDs, and various XML modules, which require
one among a list of parsers. In a case such as that, I don't know
what to do about META.yml.
Maybe there should be a way to specify that there is a requirement
for one among a list of modules? Or even that there one of several
groups of modules is required? Something like this:
requires_one_of {
dbd => {
DBD::Pg => {
DBD::Pg => 0,
DateTime::Format::Pg => 0,
},
DBD::mysql => {
DBD::mysql => 0,
DateTime::Format::mysql => 0
}
},
parser => {
XML::Parser => 0,
XML::LibXML => 0,
}
}
Here either XML::Parser or XML::LibXML is required, and either
DBD::Pg and DateTime::Format::Pg or DBD::mysql and
DateTime::Format::mysql. These could also be represented in YML, of
course.
Should I resend this proposal to the module authors list?
I think one of Ken's original ideas (and one that I like really like)
is to provide a flexible language for describing dependencies,
including situations like you describe above. IIRC, the idea was to
provide a way of saying things like:
DBD::Pg > 0 || DBD::mysql > 0
That's not bad, although it doesn't help to specify collections of
related modules like my proposal does. Also, AFAIK, the current
Module::Build syntax for version number requirements doesn't support
this, and isn't likely too, it seems to me, since module names are not
included in the version spec string. They're only the hash keys.
Debian's package manager does something different. A package can
belong to a 'virtual package'. For example there is a virtual package
for email-client. Any package that belongs to the virtual package
email-client would satisfy the dependency of another package that
depends on the that virtual package.
Hrm. That's not a bad idea. Not sure how that'd work with CPAN, though.
Bundles are the closest thing, and even with the successful
installation of a bundle doesn't mean that all of the modules it
includes have been successfully installed.
While I like debian's approach, I'm not sure it can easily be
retrofitted onto the current system. One way in which it might be
possible is to introduce macros such that you can define 'virtual
packages' in the META.yml file and the packages that satisfy it. Then
use that macro in the requirements. Of course, the thing that makes
Debians system nice is that you do not have to change the package that
has a requirement on a virtual package when a new package that also
fits the requirement is introduced. But that would require a database
of all CPAN modules.
Yes, which there is, in the module list, but it's pretty limited at
this point. I kind of like this idea, too, but I'm not sure how well it
will work. The advantage to my proposal, on the other hand, is that
it's fully self-contained in the META.yml.
module-authors might be able to come up with some other alternatives.
Moved there now. Thanks for the feedback.
Regards,
David
smime.p7s
Description: S/MIME cryptographic signature
Re: [Module::Build] requires_one_of
On Jul 16, 2004, at 4:42 PM, A. Pagaltzis wrote: I don't think it can. Take the virtual package mail-transport-agent as an example, a dependency on which can be satisfied by exim, or postfix, or sendmail, or what have you. This works because all MTAs have a very similar interface. In other cases, a standard interface can be defined by Debian and wrapper scripts or some such can be written by the respective package maintainers. Yes, but this is up to the module developer, not to CPAN. If I write my module so it can use either DBD::Pg or DBD::mysql, I want to require users to install only one or the other, not both. But whether it does work with both is my responsibility. Regards, David smime.p7s Description: S/MIME cryptographic signature
Re: [Module::Build] requires_one_of
On Jul 16, 2004, at 7:48 PM, Randy W. Sims wrote: It looks like maybe we could use 'virtual' packages like I mentioned below to solve this: YAML: requires: [db_driver]: postgresql || mysql [postgresql]: DBD::Pg: > 0 DataTime::Format::Pg: > 0 [mysql]: DBD::mysql: > 0 DataTime::Format::mysql: > 0 Square brackets denote virtual packages or macros. This should solve all the issues you mention as far as YAML goes. The Build.PL file is much more flexible; we can express these dependencies in many ways. There is not much of an issue there. Yes, that works for me. I guess one other thing that needs to be considered is: allowing other modules to make use of this. I think one of the things we wanted to allow is for the actual package being installed to access some of the same functionality in order to allow/disallow some functionality. For example, some modules will run in an enhanced mode if a module is present. Well, this is what recommends is for, no? Regards, David smime.p7s Description: S/MIME cryptographic signature
Re: [Module::Build] requires_one_of
On Jul 16, 2004, at 7:58 PM, Daniel Staal wrote: A virtual package in these cases would allow new modules to be added to the 'supports' list quite easily, and could allow for simpler test scripts. It is of limited utility, sure, but it is a non-zero utility. And the ability might encourage more people to create modules that could be virtualized this way. I guess you could say that it's of limited utility, but to my mind, it will make creating Module::Build-powered installer scripts for larger applications (such as RT and Bricolage, not to mention the 1000s of corporate applications out there) much easier. I'm glad you're in favor of the idea. :-) Regards, David smime.p7s Description: S/MIME cryptographic signature
Re: [Module::Build] requires_one_of
On Jul 17, 2004, at 4:26 AM, A. Pagaltzis wrote:
That doesn't invalidate my point that most of the time, you want
to explicitly specify the list of incompatible alternative
dependencies you have written your module against.
How does the proposed solution not do that?
As for handling the few cases where it does make sense, can't it
be done on the author side of things, such as by having a
{DBI,PGP}::Config module or some such? Its version would be
bumped when the generic interface is changed, so that one could
usefully depend on it.
There's still the issue of making people install one or another of the
array of possible modules. This is independent of the implementation,
IMO.
Regards,
David
smime.p7s
Description: S/MIME cryptographic signature
Re: [Module::Build] requires_one_of
On Jul 17, 2004, at 10:12 AM, Randy W. Sims wrote: Note that there is an implication for CPAN.pm and CPANPLUS. When a requirement with an OR condition is encountered they will have to either prompt the user for a selection or select the first option as a default. I'm not sure if there are any other compatability problems as I'm not real familiar with their implementation. But the author's should probably be consulted before making a final decision. Right, of course. Also, if there were a single module that all tools used to check requirements, it could include builtin macros for common "virtual" packages: DBD, DBM, Archiver, Encryption, ... Hrmm, yes, that would be nice, too. Did you just volunteer to write it? :-) Regards, David smime.p7s Description: S/MIME cryptographic signature
Re: [Module::Build] requires_one_of
On Jul 17, 2004, at 9:41 AM, Ken Williams wrote: Well, this is what recommends is for, no? Not quite. There's a new mechanism in M::B (it's done in CVS already, you can take a look) called "features", which formalizes the concept of optional functionality that can be turned on or off. So even if a prerequisite module is installed, you don't necessarily have to use it (e.g. sometimes even though DBD::mysql is installed, I don't want to configure Alzabo to configure & test with it). Ah, yes, that sounds nice. Cool. What are your thoughts on the virtual packages, Ken? Regards, David smime.p7s Description: S/MIME cryptographic signature
Re: [Module::Build] requires_one_of
On Jul 17, 2004, at 1:03 PM, A. Pagaltzis wrote: Because it would be very silly to have a virtual package for XML::Parser and XML::LibXML -- they can't be used as drop-in replacements for one another. It *would* be useful to be able to say "I have written this module to work with XML::Parser v.$foo or XML::LibXML v.$bar". Right, in which case you would require the virtual package. Otherwise...you wouldn't. You can depend on DBI::Config v.$foo to indicate "I need a DBD which understands version $foo of the DBD interface" in that case. And how does the installer know that? David smime.p7s Description: S/MIME cryptographic signature
Re: [Module::Build] requires_one_of
On Jul 17, 2004, at 1:09 PM, A. Pagaltzis wrote: In fact you are arguing against virtual packages if the script only works with DBD::Pg or ::mysql, but not other DBDs -- because you'll need to depend on "::Pg or ::mysql" explicitly even if there was a virtual package for "any DBD". Then I would require the "Pg_or_mysql" virtual package. Obviously being able to list alternative dependencies is of more utility than the existence of virtual packages. Not only that, but the latter would also require changes to CPAN (how likely is that to happen?), whereas a list of alternative dependencies only requires a spec for its format and an implementation in EU::MM and/or Module::Builder. How does it require changes to CPAN? Regards, David smime.p7s Description: S/MIME cryptographic signature
Re: [Module::Build] requires_one_of
On Jul 17, 2004, at 4:49 PM, A. Pagaltzis wrote: Yes, that proposal made sense, except for the name. :-) I have actually been arguing in favour of it, if you look at my mails. Oh, my bad then. Apologies. Can we use something other than "virtual package" please? Maybe "deferred depence"? Actually I don't know that this is a good name, it's just the best the comes to mind, and anything we can agree on that differs from "virtual package" would be fine, really. Let's just avoid further confusion and heartburn. Agreed. I'm racking my brains (and the brains of those around me), but I'm not coming up with anything. I like finding the right language for things, though, so I'll have to think about it... Regards, David smime.p7s Description: S/MIME cryptographic signature
Re: [Module::Build] requires_one_of
On Jul 17, 2004, at 8:57 PM, David Wheeler wrote: Agreed. I'm racking my brains (and the brains of those around me), but I'm not coming up with anything. I like finding the right language for things, though, so I'll have to think about it... Hrm, I kind of like Smylers' suggested term, "abstract". Maybe abstract_requires in Module::Build? Regards, David smime.p7s Description: S/MIME cryptographic signature
Re: [Module::Build] requires_one_of
On Jul 18, 2004, at 2:14 AM, Smylers wrote:
Also, David has an app that depends on something Pg-or-mysql-like;
suppose I do too, as do several other people. When another
Pg-or-mysql-providing module appears it doesn't make sense for every
single one of us app authors to have to note this, tweak our install
settings, and upload a new version to Cpan; that's lots of duplicated
and redundant effort.
I think that this will be the exception, really, and it's not much of
an onus for me to put something like this into my Build.PL:
requires => {
# Abstract package
db_driver => [qw(postgresql mysql)]
},
abstract_packages => {
postgresql => {
DBD::Pg => 0,
DateTime::Format::Pg => 0,
},
mysql => {
DBD::mysql => 0,
DateTime::Format::mysql => 0,
},
}
When someone adds Oracle support, then I'll be able to simply change it
to:
requires => {
# Abstract package
db_driver => [qw(postgresql mysql oracle)]
},
abstract_packages => {
postgresql => {
DBD::Pg => 0,
DateTime::Format::Pg => 0,
},
mysql => {
DBD::mysql => 0,
DateTime::Format::mysql => 0,
},
oracle => {
DBD::Oracle => 0,
DateTime::Format::Oracle => 0,
},
}
And re-release. I don't think that's too duplicating. But even for
those who do, I don't see why you wouldn't be able to simply build a
bundle that has the above requirements in it, and then all your app has
to do is require the bundle and its abstract requirements.
Regards,
David
smime.p7s
Description: S/MIME cryptographic signature
Re: [Module::Build] requires_one_of
On Jul 18, 2004, at 9:29 AM, A. Pagaltzis wrote: In terms of the word's meaning, I think that works. It just wish it was more catchy.. but if that's all we got, then that's what we got. I briefly thought about something involving "multiplexing", but I can't think of any combination of words that is both accurate and not unwieldy or awkward. Okay then. So what needs to happen to make this a reality? Modification of the META.yml spec? Modification of Module::Build? And then of CPANPLUS and CPAN.pm? Regards, David smime.p7s Description: S/MIME cryptographic signature
Re: [Module::Build] requires_one_of
On Jul 19, 2004, at 8:32 AM, Ken Williams wrote:
'dbi_support' => {
description => "Can read & write
databases",
requires => q{
DBI >= 1.0 ,
(DBD::mysql >= 1.5 ||
DBD::Postgres)
},
},
In other words, when the value of "requires" or one of the other
dependency items has a string value instead of a hash value, it means
that we're using the mini-language to express those dependencies. It
can also be used at the top level of the distribution, not associated
with any sub-feature.
What if I need
( (DBD::mysql && DateTime::Format::mysql)
|| (DBD::Pg && DateTime::Format::Pg)
)
? And how would I specify required version numbers for those modules?
Then, if we need macros (which is I think probably a better term than
"virtual packages") we can add them in, but I think we can probably
get by for a long time (perhaps eternally) without them.
Yes, but I do want the installer to report that one of the required
sets of packages for a feature is not installed. That's do-able, yes?
Regards,
David
smime.p7s
Description: S/MIME cryptographic signature
Re: [Module::Build] requires_one_of
On Jul 19, 2004, at 9:24 AM, Randy W. Sims wrote:
features => {
...
dbi_support => {
description => "Can read & write databases",
requires => {
DBI >= 1.0,
db_driver => q{ [mysql] || [pg] },
[mysql] => {
DBD::mysql => 1.5,
DataTime::Format::mysql => 0
},
[pg] => {
DBD::Pg => 0,
DataTime::Format::Pg => 0
},
},
},
This way most of the parsing is already done; Most all the terms are
already broken down into indivisible fields. It's more human readable
(IMO), though, perhaps a little more verbose. The macros help diffuse
the complexity of expressions.
Even less parsing:
features => {
...
dbi_support => {
description => "Can read & write databases",
requires => {
DBI >= 1.0,
db_driver => [qw(mysql pg)],
[mysql] => {
DBD::mysql => 1.5,
DataTime::Format::mysql => 0
},
[pg] => {
DBD::Pg => 0,
DataTime::Format::Pg => 0
},
},
},
Regards,
David
smime.p7s
Description: S/MIME cryptographic signature
Re: [Module::Build] requires_one_of
On Jul 19, 2004, at 12:27 PM, Ken Williams wrote:
You'd probably do it like this, which I think is pretty nice:
features =>
{
...
pg_support =>
{
description => "Interface with Postgres databases",
requires => q{ DBD::Pg >= 23.3 &&
DateTime::Format::Pg },
},
mysql_support =>
{
description => "Interface with MySQL databases",
requires => q{ DBD::mysql >= 17.9 &&
DateTime::Format::Pg },
},
...
}
Ah, yes, that is nice.
Though upon reflection I, too, an not sure about putting requirements
in the features section. But maybe does make sense...you could put
_all_ of the requirements there, if you needed to.
Okay, I'm happy with it. :-)
Yup. It will parse the version specifiers and report whether they're
satisfied.
Perfect. Thanks!
David
smime.p7s
Description: S/MIME cryptographic signature
Re: cpan-testers rant
On Sep 17, 2004, at 11:00 AM, David Coppit wrote: Maybe I'll have Makefile.PL actually show them the README file and make them confirm that they read it. ;) Do you list your prerequisites in PREREQ_PM in Build.PL? If you use Module::Build, it will print a warning if prerequisites aren't installed. Regards, David
Re: Old CPAN modules not being purged by authors
On Nov 24, 2004, at 8:35 AM, Hugh S. Myers wrote: Until I read this thread I hadn't given any thought to cleaning up old (presumably obsolete) modules. Now that I have, how far back should I preserve versus delete? I generally only leave the latest stable version of a module on CPAN, plus any older versions that are not compatible with the latest stable version but that a lot of people might still be using. So I have only one copy of most my modules, and two for a few of them. Regards, David
ANN: FSA::Rules 0.10
Hi All, Just wanted to follow up on the conversation of the last few days about my new module, FSA::Rules. I've just uploaded 0.10, a version which introduces a backwards incompatibility (was anyone else using it yet?) by adding state objects, per requests from a number of people. After Ovid added stracktrace methods and result and message methods in 0.07, it became clear that we really needed to encapsulate the state interface separately from the engine interface. So that's what I've done for 0.10. Now state objects will be passed to the action code references, and the current and new state objects will *both* be passed to the switch action code references. Other changes in this release: * Added an optional first argument to new() that's a hashref, so that you can set attributes in new(), start the engine up, etc. * Added a "strict" attribute to force the evaluation of all possible switch rules and to throw an exception if more than one returns a true value. * Added a notes() method for those uncomfortable with the idea of using direct hash reference on the objects. * Added states() method to get back a list of states objects in the machine. See the Changes file for a complete list of changes. Enjoy! David Begin forwarded message: From: PAUSE <[EMAIL PROTECTED]> Date: December 17, 2004 3:34:17 PM PST To: "David Wheeler" <[EMAIL PROTECTED]> Subject: CPAN Upload: D/DW/DWHEELER/FSA-Rules-0.10.tar.gz Reply-To: [EMAIL PROTECTED] The uploaded file FSA-Rules-0.10.tar.gz has entered CPAN as file: $CPAN/authors/id/D/DW/DWHEELER/FSA-Rules-0.10.tar.gz size: 19654 bytes md5: 91b8c27c554ad494707c50d514fd7af8 No action is required on your part Request entered by: DWHEELER (David Wheeler) Request entered on: Fri, 17 Dec 2004 23:32:35 GMT Request completed: Fri, 17 Dec 2004 23:34:16 GMT Thanks, -- paused, v460
ANN: FSA::Rules 0.20
Hi All, I think we've got the interface for FSA::Rules pretty well worked out now. Plus, Curtis add some slick new support for generating decision graphs from a rules engine using GraphViz! Here's the complete list of changes since 0.10: 0.20 2004-12-24T18:38:57 - Modified Synopsis to show off the result() method. - Other minor documentation fixes spotted by Curtis Poe. - Added graph support. [Curtis Poe] - Added at() method. [Curtis Poe] - Simplified synopsis. [Curtis Poe] - Added "state_class" parameter to simplify subclassing FSA::State. - A rule defined as a false scalar value, rather than a code reference, now works properly. - A successful attempt to switch states with the "strict" attribute enabled now succeeds if no other rules evaluate to true. - Each rule may now take an optional hash reference instead of a code or array reference. The hash reference may optionally specify a rule label, which eases the tracking of rules and allows graphs to generate rule labels. [Curtis Poe] - Changed the state() method to curr_state(). The old name has been deprecated, will issue a warnning when called, and will be removed in a future version. Thanks for all the help and feedback! Regards, David Begin forwarded message: From: PAUSE <[EMAIL PROTECTED]> Date: December 24, 2004 10:49:12 AM PST To: "David Wheeler" <[EMAIL PROTECTED]> Subject: CPAN Upload: D/DW/DWHEELER/FSA-Rules-0.20.tar.gz Reply-To: cpan-testers@perl.org The uploaded file FSA-Rules-0.20.tar.gz has entered CPAN as file: $CPAN/authors/id/D/DW/DWHEELER/FSA-Rules-0.20.tar.gz size: 24890 bytes md5: e1c9b8aea0738658573d2c53bf06f066 No action is required on your part Request entered by: DWHEELER (David Wheeler) Request entered on: Fri, 24 Dec 2004 18:47:01 GMT Request completed: Fri, 24 Dec 2004 18:49:12 GMT Thanks, -- paused, v460
Re: Module naming advice
On Jan 4, 2005, at 2:47 PM, Bruce J Keeler wrote: I've always felt that this one should have a lowercase name, since it's rather pragma-ish. Are pragmas allowed outside of the core Perl distribution? Maybe it should be submitted as a core pragma, actually. It's a really lightweight beast, and very useful. Would certainly get my vote. I agree that it should be lowercased; yes, there are modules on CPAN that look like pragmas (such as only). I personally would prefer, however, that the name tell me that it's doing something more than loading a class; "class" and "module" don't do that. Here are some other options: * alias (too close to "Aliased"?) * nickname * moniker * pseudonym * aka * anonym * handle (not a file handle, though, might be confusing) * label * term * shortcut I kind of like "aka", actually. But nickname, moniker, and shortcut are all good, too. Just my $0.02. Regards, David
PHP Module Name
Hi All, We're working on a new module that will allow the following: * Ability to load a PHP interpreter from Perl and use it to execute PHP code. * The PHP interpreter will be able to reach back into Perl to use data, modules, etc. * Yes, this means that PHP folks will be able to use DBI and DateTime! Anyway, we need a name for this module. The working name is "PHP::Sandwich", but that's a bit cutesy. The PHP namespace is already taken, which is too bad, because it'd be nice to be able to just do: my $php = PHP->new; $php->execute($code); So, other module names we've come up with include: Embed::PHP Interp::PHP Thoughts? Suggestions? Thanks, David
Re: PHP Module Name
On Apr 8, 2005, at 4:43 PM, Ken Williams wrote: You don't want to use the Inline::PHP namespace? No, it's not inline PHP, AFACT. Wait a sec - it looks like the PHP namespace is already taken by a module that does essentially what you're trying to do. Can you just work with Dmitry on what it lacks? I don't know. The developers working with me on the project say that it needs to be something different...George? Cheers, David
