tag:blogger.com,1999:blog-48360272576969925422024-03-08T12:34:25.409+01:00ldamidamihttp://www.blogger.com/profile/05175840149225722194noreply@blogger.comBlogger46125tag:blogger.com,1999:blog-4836027257696992542.post-44273837904700882512023-09-09T22:06:00.000+02:002023-09-09T22:06:00.586+02:00Perl cheese and wine<p>In case you didn't know from my previous posts, I've been programming in Perl for the last 25 years. <br /></p><p>Now during one week of holidays in North Italy, Alto Adige, I accidentally discovered :</p><ul style="text-align: left;"><li>a <a href="https://www.merano-suedtirol.it/it/tesimo-prissiano/mangiare-bere/prodotti-dell-alto-adige/rid-D0493CE68CC8ACA43C033D489082491D-p-perl-hof-caseificio.html" target="_blank">cheese dairy called "Perl Hof"</a>. Unfortunately it was closed when I passed there, so I couldn't taste the products.</li><li>a <a href="https://www.kellereibozen.com/selection/perl/" target="_blank">wine called "Perl"</a>, done with grape "Lagrein", very specific of that region. Quite dark in color,rich and fruity, very pleasant ... I brought a couple of bottles home :-) Come and see me if you want to taste it !</li></ul><p> </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEg5FaGGVd8NeDqnbZSYDZ_Li4geckiS1j57mlut3kqa_ihfSyiutU2XaKVR3ABKcI94mxuDuYs3uxZgyMquG-j1sUGMwJg3CFQKR_XvOdgrFWXzZzyv__nowt3H05cYZSQpVWSXjts9udtwZAxtOJIKbTPTmoQw4TTGWfRVIj_fpdBSoUKD2pzvbtGZJq8" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="2887" data-original-width="1842" height="240" src="https://blogger.googleusercontent.com/img/a/AVvXsEg5FaGGVd8NeDqnbZSYDZ_Li4geckiS1j57mlut3kqa_ihfSyiutU2XaKVR3ABKcI94mxuDuYs3uxZgyMquG-j1sUGMwJg3CFQKR_XvOdgrFWXzZzyv__nowt3H05cYZSQpVWSXjts9udtwZAxtOJIKbTPTmoQw4TTGWfRVIj_fpdBSoUKD2pzvbtGZJq8" width="153" /></a></div><br /><p></p>damihttp://www.blogger.com/profile/05175840149225722194noreply@blogger.com0tag:blogger.com,1999:blog-4836027257696992542.post-9552026567771784092018-02-24T09:13:00.001+01:002018-02-24T09:14:21.593+01:00The 3rd generation of DBIx::DataModel is on CPANThe 3rd generation of <code>DBIx::DataModel</code> has just
been <a href="https://metacpan.org/pod/DBIx::DataModel">published to CPAN</a>.<br />
<br />
<code>DBIx::DataModel</code>
is an object-relational mapping (ORM) framework for building Perl abstractions
(classes, objects and methods) that interact with relational database
management systems. It provides facilities for generating SQL queries, joining
tables automatically, navigating through the results, converting values, assembling
complex datastructures and packaging the results in various formats.Some of its
strong points are :<br />
<ol>
<li>centralized, UML-style declaration of tables and relationships
(instead of many files with declarations such as 'has_many', 'belongs_to',
etc.)
</li>
<li>limited coupling with the database schema : there is no need to
declare every column of every table; DBIx::DataModel only needs to know about
tables, associations, primary keys and foreign keys
</li>
<li>exposure of database operations like joins, bulk updates, subqueries,
etc. The database is not hidden behind object-oriented programming concepts, as
some other ORMs try to do, but rather made to explicitly collaborate with the
object-oriented layer.
</li>
<li>efficiency through a very lightweight infrastructure and through fine tuning of
interaction with the DBI layer (prepare/execute, fetch into reusable memory
location, etc.)
</li>
<li>usage of <a href="https://metacpan.org/pod/SQL::Abstract::More">SQL::Abstract::More</a>
for an improved API over <a href="https://metacpan.org/pod/SQL::Abstract">SQL::Abstract</a>
(named parameters, additional clauses, simplified 'order_by', support for
values with associated datatypes, etc.)
</li>
<li>clear conceptual distinction between:
<ul>
<li>data sources (tables and joins),
</li>
<li>database statements (stateful objects representing stepwise
building of an SQL query and stepwise retrieval of results),
</li>
<li>data rows (lightweight hashrefs containing nothing but column
names and values)
</li>
</ul>
</li>
<li>simple syntax for joins, with the possibility to override default
INNER JOIN/LEFT JOIN properties, and with clever usage of Perl multiple
inheritance for simultaneous access to the methods of all tables that
participate in that join
</li>
<li>nested, cross-database transactions
</li>
<li>choice between 'single-schema' mode (default, more economical)
and 'multi-schema' mode (optional, more flexible, but a little more costly in
memory)
</li>
<li>detailed documentation exposing not only the surface API but also the internal architecture and design principles
</li>
</ol>
Initially published in 2005, <code>DBIx::DataModel</code> had a 1<sup>st</sup> refactoring
in 2008 and a 2<sup>nd</sup> refactoring in 2011. Novelties brought by this 3<sup>rd</sup>
refactoring of 2018 are : <br />
<ol>
<li>architectural simplification : suppression of the ConnectedSource class
</li>
<li>new extensible
architecture for result kinds produced by calls to <a href="https://metacpan.org/pod/distribution/DBIx-DataModel/lib/DBIx/DataModel/Doc/Reference.pod#select">select()</a>.
Builtin result kinds include various datastructure and file formats ; applications
can easily plug additional result kinds.
</li>
<li>facilities for
switching between several database schemas within the same database connection
</li>
<li>method <a href="https://metacpan.org/pod/distribution/DBIx-DataModel/lib/DBIx/DataModel/Doc/Reference.pod#do_after_commit()">do_after_commit</a>()
for registering coderefs to be executed after the end of the outermost
transaction.
</li>
<li>option <a href="https://metacpan.org/pod/distribution/DBIx-DataModel/lib/DBIx/DataModel/Doc/Reference.pod#join_with_USING">join_with_USING</a>
for generating joins of shape « Table1 JOIN Table 2 USING (common_key) »
</li>
<li>restructuring
of the <a href="https://metacpan.org/pod/distribution/DBIx-DataModel/lib/DBIx/DataModel/Doc/Reference.pod#update">update()</a>
method for easier extension by application subclasses
</li>
<li>complete revision of the documentation
</li>
</ol>
damihttp://www.blogger.com/profile/05175840149225722194noreply@blogger.com1tag:blogger.com,1999:blog-4836027257696992542.post-21831167835348832702018-02-17T15:29:00.000+01:002018-02-23T16:43:05.883+01:00Very positive and refreshing articles on Perl 5 -- example for embedded systems Michel Conrad recently wrote two very positive articles on Perl 5. Those were relayed on the <a href="https://www.linkedin.com/company/the-perl-group/" target="_blank">LinkedIn Perl group</a> but I haven't seen them on usual Perl sites, so I share them here in the hope they get propagated better. :<br />
<br />
<a href="https://opensource.com/article/18/1/why-i-love-perl-5" target="_blank"> https://opensource.com/article/18/1/why-i-love-perl-5</a><br />
<br />
<a href="https://opensource.com/article/18/1/my-delorean-runs-perl" target="_blank">https://opensource.com/article/18/1/my-delorean-runs-perl</a><br />
<br />
The second article is very interesting in that it shows an unusual application area for Perl : realtime graphics for a car dashboard ! This reminded me of a very interesting presentation many years ago at the <a href="http://articles.mongueurs.net/comptes-rendus/fpw-2005.html" target="_blank">French Perl Workshop 2005</a> , where we saw an application driving all vehicles on the apron of Port Airport.<br />
<br />
<br />
<br />
<br />damihttp://www.blogger.com/profile/05175840149225722194noreply@blogger.com2tag:blogger.com,1999:blog-4836027257696992542.post-11966266763571911762014-09-07T03:08:00.000+02:002014-09-07T03:08:40.323+02:00back from Swiss Perl Workshop 2014The second <a href="http://act.perl-workshop.ch/spw2014/" target="_blank">Swiss Perl Workshop</a> just ended, and it was really nice.<br />
<br />
I must confess that I was quite skeptical when Roman and Matthias first came up with such an idea, thinking that Swiss french people would rather go the <a href="http://journeesperl.fr/fpw2014/" target="_blank">Journées Perl</a> in Paris, and Swiss german people would rather go to the <a href="http://www.perl-workshop.de/de/index.html" target="_blank">Deutscher Perl Workshop</a>. But I was wrong : people came, and I was very happy to encounter new local people doing Perl. The organization was <a href="https://de.wiktionary.org/wiki/tiptop" target="_blank">tip-top</a> : well-chosen location in the center of Switzerland, in a <a href="http://www.floerli-olten.ch/rooms/index.de.html" target="_blank">cosy, ancient house</a>, nice food eaten in the garden, with good <a href="https://en.wikipedia.org/wiki/Valpolicella" target="_blank">Valpolicella ripasso</a> wine.<br />
<br />
For this event I expanded my YAPC::EU lightning talk on virtual tables for SQlite : the expanded slides are online at <a href="http://www.slideshare.net/ldami/sq-lite-virtualtables" target="_blank">http://www.slideshare.net/ldami/sq-lite-virtualtables</a>. The other talk on <a href="https://metacpan.org/pod/App::AutoCRUD" target="_blank">App::AutoCRUD</a> was the same as in YAPC (slides <a href="http://www.slideshare.net/ldami/app-auto-crud" target="_blank">here</a>).<br />
<br />
Thanks again to Roman and Matthias, and see you next year.damihttp://www.blogger.com/profile/05175840149225722194noreply@blogger.com0tag:blogger.com,1999:blog-4836027257696992542.post-39720047397464315152014-07-30T08:37:00.000+02:002014-07-30T08:37:12.011+02:00Plack::App::* namespace is not for apps - so which is the proper CPAN namespace ?OOps ... I just realized that I had misunderstood the intent of the <span style="font-family: "Courier New",Courier,monospace;">Plack::App</span> namespace : the top-level Plack doc explicitly says :<br />
<blockquote class="tr_bq">
<i><b>DO NOT USE</b> Plack:: namespace to build a new web application or a
framework. It's like naming your application under CGI:: namespace if
it's supposed to run on CGI and that is a really bad choice and
would confuse people badly.</i></blockquote>
and the<a href="http://advent.plackperl.org/2009/12/day-24-explore-more-and-get-in-touch-with-plack-devs.html" target="_blank"> 2009 Plack Advent Calendar</a> goes even further with<br />
<blockquote class="tr_bq">
<i>Think twice before using Plack::App::* namespace. Plack::App namespace is for middleware components that do not act as a wrapper but rather an endpoint. Proxy, File, Cascade and URLMap are the good examples. If you write a blog application using Plack, <b>Never</b> call it Plack::App::Blog, okay? Name your software by what it does, not how it's written.</i></blockquote>
OK, sorry, I got this wrong when publishing<span style="font-family: "Courier New",Courier,monospace;"> <a href="https://metacpan.org/pod/Plack::App::AutoCRUD" target="_blank">Plack::App::AutoCRUD</a></span> -- but to my excuse, I'm not alone, several other CPAN authors did the same.<br />
<br />
The app is quite young, so it is still time to repair its name (even if this operation will be quite tedious, because it involves changes in all module sources, in the CPAN distribution, in the <a href="https://github.com/damil/Plack-App-AutoCRUD" target="_blank">github repository name</a>, and in the<a href="http://act.yapc.eu/ye2014/talk/5516" target="_blank"> upcoming YAPC::EU::2014 talk</a>). But if I want to be a good citizen and engage into such an operation, what should be the proper name ? The CPAN namespace is becoming a bit crowded, as <a href="http://blogs.perl.org/users/joel_berger/2012/01/on-cpan-namespaces.html" target="_blank">already noted 2 years ago by Joel Berger</a>. For choosing a name, there seem to be several controversial and perhaps contradictory principles :<br />
<ul>
<li><b>CPAN is for modules, not for apps</b> : this was argued in 2008 in a <a href="http://www.perlmonks.org/?node_id=685620" target="_blank">Perlmonk discussion on the same topic</a> ; however, many people replied in disagreement. I disagree too : publishing a Perl app on CPAN fully makes sense because we take advantage of the CPAN infrastructure for tests, dependency management, publication, etc. Furthermore, applications can be extended or forked, just like modules, so CPAN is a perfect environment for sharing.<br /></li>
<li><b>publish under the App::* namespace</b> : this is the <a href="https://pause.perl.org/pause/query?ACTION=pause_namingmodules#App" target="_blank">PAUSE recommendation</a>. But applications in the <span style="font-family: "Courier New",Courier,monospace;">App::*</span> namespace are mainly command-line utilities, which is quite different from Web applications. As a matter of fact, nobody used yet the <span style="font-family: "Courier New",Courier,monospace;">App::Web</span> namespace -- maybe it's time to start ?<br /><b> </b></li>
<li><b>use a ::Web or ::WebApp suffix at the <i>end</i> of the module name : </b>I never saw this as a recommendation, but nevertheless many distributions adopted this approach. This is certainly appropriate if the main goal is to publish a functionality <span style="font-family: "Courier New",Courier,monospace;">Foo::Bar</span>, and by the way, there is also a web app at <span style="font-family: "Courier New",Courier,monospace;">Foo::Bar::WebApp</span>. But if the purpose of the whole distribution is just a web app, this approach tends to create a new top-level namespace, which is not considered good practice. Should I choose <span style="font-family: "Courier New",Courier,monospace;">AutoCRUD::WebApp</span> ? I think not, because other people might want to use the<span style="font-family: "Courier New",Courier,monospace;"> AutoCRUD::*</span> namespace.<br /><b> </b></li>
<li><b>avoid top-level namespaces</b> : this used to be an important recommendation, but it doesn't seem to be well respected any more :-( -- nowadays I see more and more CPAN distributions taking up top-level names. I won't cite any particular example, not to offend anybody, but it's quite obvious if you look at the <a href="http://www.cpan.org/modules/by-module/" target="_blank">list of top-level namespaces</a> .... and unfortunately many of those top-level names give no clue whatsoever about what kind of functionality will be found in the associated distribution.<br /></li>
<li><b>hide the technology</b> <b>underlying your app </b>: the Plack argument above says that the app should be named from its functionality, not from its implementation technology. Well ... I'm not so sure that this is always appropriate. Many modules sit under the <span style="font-family: "Courier New",Courier,monospace;">Tie::Hash::*</span> namespace, just because they used the tied hash technology, for providing various kinds of functionalities.<br />Concerning "Plack", when I see that keyword in a module name, I know that a) this is Web technology, and b) this will work on any kind of web server (as opposed to modules names containing "Apache" or "Apache2"), and I consider this to be useful information for a potential user. On the opposite, I didn't want to name my module <span style="font-family: "Courier New",Courier,monospace;">DBIx::DataModel::AutoCRUD</span>, even if it uses <a href="https://metacpan.org/pod/DBIx::DataModel" target="_blank">DBIx::DataModel</a> quite heavily, because that's not hardwired into the architecture and I could easily imagine a later adaptation for supporting as well <a href="https://metacpan.org/pod/DBIx::Class" target="_blank">DBIx::Class</a>.</li>
</ul>
So in the end I will probably end up with something like <span style="font-family: "Courier New",Courier,monospace;">App::Web::AutoCRUD</span> or <span style="font-family: "Courier New",Courier,monospace;">WebApp::AutoCRUD</span> ... unless somebody comes up with a better suggestion ! <br />
<br />
PS : see also <a href="https://metacpan.org/pod/Catalyst::Plugin::AutoCRUD" target="_blank">Catalyst::Plugin::AutoCRUD</a> .. which can be used either as a Catalyst plugin or as an application on its own.<br />
<ul>
</ul>
<br />
<br />
<br />
<br />
<br />damihttp://www.blogger.com/profile/05175840149225722194noreply@blogger.com1tag:blogger.com,1999:blog-4836027257696992542.post-48494221645115928762014-07-11T08:44:00.001+02:002014-07-11T08:44:28.518+02:00Perl virtual tables for DBD::SQLite : ready to testFollowup to my<a href="http://ldami.blogspot.com/2014/07/project-perl-virtual-tables-for.html" target="_blank"> previous article</a> : a first draft of Perl virtual table support for DBD::SQLite is available at <a href="https://github.com/DBD-SQLite/DBD-SQLite/tree/vtab" target="_blank">https://github.com/DBD-SQLite/DBD-SQLite/tree/vtab </a>.<br />
<br />
This is still alpha software, but it shows the idea; I still don't know when this work will be mature enough for a CPAN publication.<br />
<br />
Two examples of virtual table modules are bundled with the distribution :<br />
<ul>
<li><b>FileContent </b>: implements a virtual column that exposes file contents. This is especially useful<br />in conjunction with a SQLite FTS fulltext index; see the doc in Fulltext_search.pod</li>
<li><b>PerlData </b>: binds a virtual table to a Perl array within the Perl program. This can be used for simple import/export operations, for debugging purposes, for joining data from different<br />sources, etc.</li>
</ul>
I'm currently thinking of one more example , which would be fun to play with : a virtual table that would proxy to another DBI connection. Then we could join data from various sources, using SQLite's features to do the joining work. Sounds quite exciting, but at this point this is just an idea.<br />
<br />
Thanks to Salvador Fandiño who pointed me to <a href="https://metacpan.org/pod/SQLite::VirtualTable" target="_blank">https://metacpan.org/pod/SQLite::VirtualTable</a>, which is similar in idea but more meant to embed a Perl interpreter inside a sqlite application, rather than the other way around; this code helped me build the DBD::SQLite version.<br />
<br />
Of course any comments/suggestions are welcome.<br />
damihttp://www.blogger.com/profile/05175840149225722194noreply@blogger.com0tag:blogger.com,1999:blog-4836027257696992542.post-50439824577163193062014-07-04T08:57:00.000+02:002014-07-04T08:57:11.445+02:00project : Perl virtual tables for DBD::SQLite During the year I have more and more management tasks and less time for programming. So for the holidays I wanted a change and decided to engage into a really "hardcore programming" project, namely to add support for Perl virtual tables within the DBD::SQLite database driver. SQLite has this notion of "virtual tables" which look like regular tables but are implemented through callback routines. This project implies some C programming, using Perl XS API, and the delicate part is to design some appropriate glue between SQLite's notion of "object-oriented", through extensible C structures and callbacks, and Perl's object-oriented features.<br /><br />At the beginning I wasn't even sure if such a project would be feasible, but now it is slowly taking shape and I'm pretty confident that it will eventually reach something usable. The concept is quite similar to Perl's tied variables, where a published API is reused for accessing many different kinds of data; except that here the published API is SQL instead of hashes or array operators. As a result, we could have virtual tables bound to the filesystem, to the Win32::Registry, to some configuration data, or any other accessible resource. This will open a new field for lots of creative ideas.<br /><br />My main motivation for doing this work is to be able to build a framework for collections of documents, using SQLite for the fulltext index, and using the filesystem for storing document content : this will be a much more powerful replacement for my very old <a href="https://metacpan.org/pod/File::Tabular::Web::Attachments::Indexed" target="_blank">File::Tabular::Web::Attachment::Indexed</a> module. That module is still heavily used at Geneva courts of law, but now we have 10 years of data, and the old architecture is clearly showing its limits.<br />
<br />
For the virtual tables project I need some test cases, so if anybody has ideas about Perl-accessible data to be published as an SQL table, I'm interested. <br />
<br />
<br />
<br />
<br />damihttp://www.blogger.com/profile/05175840149225722194noreply@blogger.com4tag:blogger.com,1999:blog-4836027257696992542.post-88608177476886439532014-06-23T21:07:00.001+02:002014-06-23T21:07:12.833+02:00Perl smartmatch : what now ?Sorry to wake up an old discussion, but ... does anybody have a clear idea of what is going to happen to smartmatch ?<br />
<br />
Our team maintains dozens of internal applications and modules containing "given/when" and smartmatch statements. Most of this code was written between 2007 and 2012 -- remember, at that time smartmatch was an official feature, never mentioned as being "experimental", so we happily used it in many places. The reasons for using smartmatch were quite modest :<ul>
<li>match a scalar against an array</li>
<li>match 2 scalars, without a warning when one of the scalars is undef</li>
<li>more readable switch statements, thanks to "given/when"</li>
</ul>
When 5.18 came out, I was quite worried about the regression of smartmatch to "experimental" status, but I was confident that things would be settled in 5.20, so I decided not to upgrade (we still use 5.14). Now 5.20 is out .. and nothing has changed about smartmatch, without even a clue about how this is going to evolve.<br />
<br />
Our servers cannot easily upgrade to 5.20, because this would throw warnings all over the place. I tried to find a way to globally turn off these warnings (like set PERL5OPT=-M-warnings=experimental::smartmatch, or PERL5OPT=-M=<a href="https://metacpan.org/pod/experimental" target="_blank">experimental::smartmatch</a>), but this doesn't work because the "no warnings" pragma is lexically scoped, so global settings are not taken into account. <br />
<br />
So my options are :<ol>
<li>don't change anything, don't upgrade, and wait for 5.22, hoping that some reasonable form of smartmatch will be reintroduced into the core</li>
<li>revise all source files, adding a line "use experimental qw/smartmatch/;" at the beginning of each lexical scope ... but I have no guarantee that this will still work in future versions</li>
<li>revise all source files, removing the given/when/smartmatch statements and replacing them with plain old Perl, or with features from some CPAN modules like <a href="https://metacpan.org/pod/match::smart" target="_blank">match::smart</a> or <a href="https://metacpan.org/pod/Smart::Match" target="_blank">Smart::Match</a> ... but it would be a pity to engage in such work if regular smartmatch comes back in a future version of Perl.</li>
</ol>
As you can see, none of these options is really satisfactory, so I would be interested in hearing if other companies are in the same situation and how they decided to handle it.<br />
<br />
By the way, I love the new Perl way of introducing new features as "experimental", until they become stable and official ... but this only works well when the experimental status is declared<strong> </strong><em>from the start</em>. The problem with smartmatch is that it had been official for several years, before being retrograted to experimental. Agreed, the full semantics of smartmatch as published in 10.0 had inconsistencies, but throwing away the whole thing is a bit too harsh -- I'm sure that many users like me would be happy with a reasonable subset of rules for matching common cases.<br />
<div>
Thanks in advance, Laurent Dami</div>
<div>
</div>
damihttp://www.blogger.com/profile/05175840149225722194noreply@blogger.com13tag:blogger.com,1999:blog-4836027257696992542.post-7817889498096831002013-05-25T09:38:00.001+02:002013-05-25T20:28:11.821+02:00surprising interaction betwen list context and range operatorI was preparing a quiz for Perl programmers, and wanted a question on the difference between arrays and lists. So the question was : what do you get in <span style="font-family: "Courier New", Courier, monospace;">$x</span> and<span style="font-family: "Courier New", Courier, monospace;"> $y</span> after<br />
<br />
<span style="font-family: "Courier New", Courier, monospace;">my @tab = ( 1, 3, 6..9 );<br />my $x = @tab;<br />my $y = ( 1, 3, 6..9 );</span><br />
<br />
where I expected <span style="font-family: "Courier New", Courier, monospace;">$x</span> to be 6 (the number of items) and<span style="font-family: "Courier New", Courier, monospace;"> $y</span> to be 9 (the last element), as documented in <a href="https://metacpan.org/module/perldata" target="_blank">perldata</a>. But before distributing the quiz I thought it was worth a test ... and indeed it was! To my surprise, <span style="font-family: "Courier New", Courier, monospace;">$y</span> turns out to be an empty string. It took me some time to find out why : with<br />
<span style="font-family: Courier New;"></span><br />
<span style="font-family: Courier New;">my $y = ( 1, 3, 6, 7, 8, 9 );</span><br />
<br />
the result is 9 indeed. But with <br />
<br />
<span style="font-family: Courier New;">my $y = ( 1, 3, 6..9 );</span><br />
<br />
<br />
the interpreter does not build the range in list context, and then keep the last element. What happens instead is that it throws away the beginning of the list (there is even a warning about that), and then evaluates <br />
<br />
<span style="font-family: Courier New;">my $y = 6..9;</span><br />
<br />
<br />
in <em>scalar</em> context; where 6..9 is no longer a range, but a flip-flop operator. Now since the left-hand side is true, that operator is supposed to be true, right ? Well, no, because 6 is a constant, and in that case, <a href="https://metacpan.org/module/perlop#Range-Operators" target="_blank">perlop</a> tells us that the flip-flop is "considered true if it is equal (<code>==</code>) to the current input line number (the <code>$.</code> variable)". So $y ends up being an empty string, while <br />
<br />
<span style="font-family: Courier New;">my $six = 6;</span><br />
<span style="font-family: Courier New;">my $nine = 9;</span><br />
<span style="font-family: Courier New;">my $y = $six..$nine;</span><br />
<br />
<br />
would yield 1E0!<br />
<br />
I couldn't be <em>that</em> nasty to the interviewed programmers, so in the end that question will not be part of the quiz.<br />
<br />damihttp://www.blogger.com/profile/05175840149225722194noreply@blogger.com4tag:blogger.com,1999:blog-4836027257696992542.post-16003279548597323092013-02-17T09:07:00.001+01:002013-02-17T09:07:40.299+01:00Slices of method calls within an object<a href="http://ldami.blogspot.fr/2009/08/object-oriented-accessors-considered.html" target="_blank">Several years ago</a> I complained that object accessors prevent you from using some common Perl idioms; in particular, you couldn't take a slice of several attributes within an object.<br />
<br />
Now I just discovered the <a href="https://metacpan.org/module/Want" target="_blank">Want</a> module; this is great for playing with lvalue subroutines. With the help of this module, I was finally able to use slices of method calls within an object : see <a href="https://metacpan.org/module/Method::Slice">https://metacpan.org/module/Method::Slice</a> . There are some caveats in comparison with a usual hash slice, but nevertheless the main point is there : you can extract some values :<br />
<br />
<pre> my @coordinates = mslice($point, qw/x y/);
</pre>
or even assign to them: <br />
<br />
<pre> (mslice($point, qw/x y/)) = (11, 22);
</pre>
This was written just for fun ... but in the end I might use it in real code, because in some situations, I find slices to be more compact and high-level than multiple assignment statements.damihttp://www.blogger.com/profile/05175840149225722194noreply@blogger.com2tag:blogger.com,1999:blog-4836027257696992542.post-89930613695049180432012-12-02T05:53:00.001+01:002012-12-02T05:53:27.254+01:00How to test if something is a Perl class ?For Data::Domain I needed a way to test if something is a Perl class. Since UNIVERSAL is the mother of all classes, it seemed to make sense to define the test as<br />
<br />
<span style="font-family: Courier New;">defined($_) && !ref($_) && $_->isa('UNIVERSAL')</span><br />
<br />
Other people did it through <span style="font-family: "Courier New", Courier, monospace;">$_->can('can') </span><span style="font-family: inherit;">or </span><span style="font-family: "Courier New", Courier, monospace;">UNIVERSAL::can($_, 'can'). </span>Both ways used to work fine, but this is no longer true since <a href="https://rt.perl.org/rt3/Public/Bug/Display.html?id=47113" target="_blank">June 22, 2012</a> (bleadperl commit 68b4061) : now just any string matches these conditions. <br />
<br />
At first I found this change a bit odd, but somehow it makes sense because any string will answer to the 'can' and 'isa' methods. Also, <span style="font-family: "Courier New", Courier, monospace;">bless({}, 'Foo') </span><span style="font-family: inherit;">and </span><span style="font-family: "Courier New", Courier, monospace;">'Foo'</span><span style="font-family: inherit;"> now return consistent answers for ->isa() and for ->can(), which was not the case before. So let's agree that this change was a good step.</span><br />
<br />
<br />
But now it means that while every object or class is a UNIVERSAL, the reverse is not true : things that are UNIVERSAL are not necessarily objects or classes. Hum ... but what "is a class", really ?<br />
<br />
Moose type 'ClassName' defines this through Class::Load::is_class_loaded, which returns true if this is a package with a $VERSION, with an @ISA, or with at least one method. By this definition, an empty package is not a class. However, perldoc says that a class is "just a package", with no restriction.<br />
<br />
So after some thoughts I ended up with this implementation :<br />
<br />
<span style="font-family: "Courier New", Courier, monospace;">defined($_) && !ref($_) && $_->can($_)</span><br />
<br />
<span style="font-family: inherit;">This returns true for any defined package, false otherwise, and works both before and after June 22.</span><br />
<br />
Thoughts ?<br />
<br />
<br />
<br />
<br />
damihttp://www.blogger.com/profile/05175840149225722194noreply@blogger.com6tag:blogger.com,1999:blog-4836027257696992542.post-64552714201389567992012-12-01T07:38:00.000+01:002012-12-01T07:38:50.881+01:00Hash key order : beware of implicit assumptionsPerl hashes are not ordered, so one is not supposed to make assumptions about the key order. I thought I did not ... but Perl 5.17.6 showed me that I was wrong !<br />
<br />
About two weeks ago I started receiving report about test failures which were totally incomprehensible to me. Since I work on Windows, I had no bleadperl environment, so it was hard to guess what was wrong just from the test reports. Andreas König kindly opened a <a href="https://rt.cpan.org/Ticket/Display.html?id=81485" target="_blank">ticket</a> in which he spotted that the problem was related to a <a href="http://perl5.git.perl.org/perl.git/commit/7dc8663964c66a698d31bbdc8e8abed69bddeec3" target="_blank">recent change in bleadperl</a> : now Perl not only makes no guarantee about the key order, it even guarantees that the key order will be different through several runs of the same program!<br />
<br />
This convinced me of investing some time to get a bleadperl environment on my Windows machine : <a href="https://my.vmware.com/web/vmware/free#desktop_end_user_computing/vmware_player/5_0" target="_blank">VMware player</a> + a <a href="http://vmware.pouf.org/" target="_blank">virtual Unbutu</a> + <a href="https://metacpan.org/module/App::perlbrew" target="_blank">perlbrew</a> did the job perfectly. Now I could start working on the bug.<br />
<br />
The point were I was making an implicit assumption was a bit nasty, so I thought it was worth writing this post to share it : the code in <a href="https://metacpan.org/module/SQL::Abstract::More" target="_blank">SQL::Abstract::More</a> more or less went like this :<br />
<br />
<span style="font-family: "Courier New", Courier, monospace;"> my $ops = join "|", map quotemeta, keys %hash;</span><br />
<span style="font-family: Courier New;"> my $regex = qr/^($ops)?($rest_of_regex)/;</span><br />
<br />
<span style="font-family: inherit;">See the problem ? The regex starts with an alternation derived from the hash keys. At first glance one would think that the order of members in the alternation is not important ... except when one member is a prefix of the other, because the first member wins. For example, matching "absurd" against </span><span style="font-family: "Courier New", Courier, monospace;">qr/^(a|ab|abc)?(.*)/ </span><span style="font-family: inherit;">is not the same as</span><span style="font-family: inherit;"> <span style="font-family: "Courier New", Courier, monospace;">qr/^(abc|ab|a)?(.*)/</span><span style="font-family: inherit;"> : in one case $1 will contain 'a', in the other case it will contain 'ab'.</span></span><br />
<br />
To fix the problem, the code above was <a href="https://github.com/damil/SQL-Abstract-More/commit/cc9c9606e4395427f5d79bc6c96e303da6e7251e" target="_blank">rewritten</a> to put the longest keys first, and everything is fine again.<br />
<br />
damihttp://www.blogger.com/profile/05175840149225722194noreply@blogger.com6tag:blogger.com,1999:blog-4836027257696992542.post-63782969206354911482012-11-10T21:27:00.001+01:002012-11-10T21:27:28.528+01:00updated Data::Domain and new Test::InDomainThis is to announce new modules on CPAN:<br />
<br />
a) module <a href="https://metacpan.org/module/Data::Domain" target="_blank">Data::Domain</a>, written a couple of years ago for checking input from Web forms, now has number of new functionalities in v1.02 : new builtin domains 'Nat', 'Handle', 'Regexp', 'Obj', 'Class', 'Ref', new properties like -isweak, -readonly, etc., and new experimental support for checking method calls and coderef calls. Also, it now relies on <a href="https://metacpan.org/module/Scalar::Does" target="_blank">Scalar::Does</a> (for having a nice uniform way of checking what references "do" either as builtin Perl operations, or through overloaded methods), and on <a href="https://metacpan.org/module/Sub::Exporter" target="_blank">Sub::Exporter</a> (for allowing clients to rename the imported functions). If you need to check deep datastructures against complex constraints, possibly with contextual dependencies or even recursive rules, then this module may be of interest to you. <br />
<br />
b) the new module <a href="https://metacpan.org/module/Test::InDomain" target="_blank">Test::InDomain </a>is a wrapper around Data::Domain for writing automated tests; it sits more or less in the same niche as <a href="https://metacpan.org/module/Test::Deep" target="_blank">Test::Deep</a>, but with a different API and some differences in functionalities.<br />
<br />
I hope it might be useful to some of you. Have a look, and let me know of any comments/suggestions.damihttp://www.blogger.com/profile/05175840149225722194noreply@blogger.com0tag:blogger.com,1999:blog-4836027257696992542.post-90656136652945677752012-10-19T02:38:00.000+02:002012-10-19T02:38:46.084+02:00Rediscovering smart matchPerl's "smart match" operator came with Perl 5.10 in 2007 (as a matter of fact, it was released during the <a href="http://perlbuzz.com/2007/11/perl-5100-rc1-is-now-available.html" target="_blank">French Perl Workshop 2007</a>, and this is where I also learned about this new feature). I immediately thought : "Wow, this is great, it is going to dramatically change my way of programming!".<br />
<br />
Unfortunately, our infrastructure at work still remained Perl 5.8 for several years, and by the time I was at last able to make use of smart match, I had nearly forgotten all its virtues. I have a couple of lines of code with "given/when" statements, but that's mostly it.<br />
<br />
However, after having recently attended the excellent class by Damian Conway on <a href="http://damian.conway.org/Courses/AdvProgPerl.html" target="_blank">Advanced Perl Programming Techniques</a>, smart match came back to my mind. I know, it's been criticized for being too complex in some of its matching rules; but the basic rules are great and yield more readable and more flexible code.<br />
<br />
Here are some examples that I'm refactoring right now :<br />
<h4>
List membership</h4>
Instead of <br />
<br />
<span style="font-family: "Courier New", Courier, monospace;">if ($data =~ /^(@{[join '|', @array]})$/) {...}</span><br />
<br />
<span style="font-family: inherit;">or</span><br />
<br />
<span style="font-family: "Courier New", Courier, monospace;">use List::MoreUtils qw/any/;</span><br />
<span style="font-family: Courier New;"> if (any {$data eq $_} @array) {...}</span><br />
<br />
<span style="font-family: inherit;">write</span><br />
<br />
<span style="font-family: Courier New;"> if ($data ~~ @array) {...}</span><br />
<h4>
No need to test for undef</h4>
Instead of<br />
<br />
<span style="font-family: "Courier New", Courier, monospace;"> my $string = $hashref->{some_field} || '';</span><br />
<span style="font-family: Courier New;"> if ($string eq 'foo') {...}</span><br />
<br />
<span style="font-family: inherit;">write</span><br />
<br />
<span style="font-family: Courier New;"> if ($hashref->{some_field} ~~ 'foo') {...}</span><br />
<h4>
No need to test for numish</h4>
Instead of<br />
<br />
<span style="font-family: "Courier New", Courier, monospace;"> use Scalar::Util qw/looks_like_number/;</span><br />
<span style="font-family: Courier New;"> my $both_nums = looks_like_number($x) </span><br />
<span style="font-family: Courier New;"> && looks_like_number($y);</span><br />
<span style="font-family: Courier New;"> if ($both_nums ? $x == $y : $x eq $y) {...}</span><br />
<br />
<span style="font-family: inherit;">write</span><br />
<br />
<span style="font-family: "Courier New", Courier, monospace;"> if ($x ~~ $y) {...}</span>damihttp://www.blogger.com/profile/05175840149225722194noreply@blogger.com1tag:blogger.com,1999:blog-4836027257696992542.post-14796224712361212722012-06-29T17:00:00.000+02:002012-06-29T17:00:12.902+02:00My slides for FPW12 are onlineFor info, the slides of my talks at the <a href="http://journeesperl.fr/fpw2012/welcome.html" target="_blank">French Perl Workshop 2012</a> are now online :<br />
<br />
<ul>
<li>a <a href="http://www.slideshare.net/ldami/dbixclass-vs-dbixdatamodel" target="_blank">comparison of Perl ORMs DBIx::Class and DBIx::DataModel</a></li>
<li>a CPAN <a href="http://www.slideshare.net/ldami/sql-abstract-fromquery" target="_blank">module for generating SQL::Abstract datastructures from a web form</a></li>
</ul>damihttp://www.blogger.com/profile/05175840149225722194noreply@blogger.com1tag:blogger.com,1999:blog-4836027257696992542.post-1297274785097576982012-06-07T00:04:00.002+02:002012-06-07T00:04:57.337+02:00Translating user queries into SQL::Abstract (using Regexp::Grammars)As mentioned in my <a href="http://ldami.blogspot.ch/2012/05/who-is-using-regexpgrammars.html" target="_blank">previous post </a>, I've been quite interested in <a href="https://metacpan.org/module/SQL::Abstract" target="_blank">Regexp::Grammars</a> recently.<br />
<br />
My latest project with it is <a href="https://metacpan.org/module/SQL::Abstract::FromQuery" target="_blank">SQL::Abstract::FromQuery</a> , just released to CPAN. This is a module to help building Web applications with complex search forms. It translates user input, as obtained from an HTML form, into a datastructure suitable as a <span style="font-family: "Courier New", Courier, monospace;">%where</span> clause for <a href="https://metacpan.org/module/SQL::Abstract" target="_blank">SQL::Abstract</a>; that module will in turn produce the SQL statement and bind parameters to query the database.Users can type regular values, comparison operators, patterns, etc <br />
<br />
<br />
Technically, this uses many advanced features of <a href="https://metacpan.org/module/SQL::Abstract" target="_blank">Regexp::Grammars</a> : list results,"autoactions", named grammars, multiple inheritance of grammars and of actions, etc.; so if you ever wondered what these features are good for, here is an example. It also uses some great features of Perl, like dynamic loading of components, dynamic building of an anonymous subclass ... I really feel happy to work with a language that has such a wonderful toolbox.<br />
<br />
Nate Wiger, the original author of <a href="https://metacpan.org/module/SQL::Abstract" target="_blank">SQL::Abstract</a>, already had this vision of translating Web forms into SQL queries; here we elaborate on that idea and support some more details.<br />
<br />
The module is still in early infancy, so avoid using it in production (the API probably needs some improvements); suggestions are welcome. Enjoy!<br />
<br />
<br /><br />
<br />
<br />damihttp://www.blogger.com/profile/05175840149225722194noreply@blogger.com1tag:blogger.com,1999:blog-4836027257696992542.post-62940681202595665972012-05-20T11:18:00.000+02:002012-05-20T11:18:25.869+02:00Who is using Regexp::Grammars ?I've been using <a href="https://metacpan.org/module/Regexp::Grammars" target="_blank">Regexp::Grammars</a> for a couple of projects and I find this module really amazing : so much power in such a compact form ! Actually, the whole thing is a gigantic hack, but an extremely clever hack. The learning curve is steep, but once you are used to it, playing with callback actions, grammar inheritance trees or fancy "result distillation" strategies is a joy. The only drawback is that running callback functions within the Perl regexp compiler is sometimes tricky (in Perl versions prior to 5.14, the regexp engine is not reentrant; and debugging may be acrobatic).<br />
<br />
I just had a look at the<a href="http://deps.cpantesters.org/depended-on-by.pl?module=Regexp%3A%3AGrammars" target="_blank"> reverse dependencies</a> and was very surprised to find so few CPAN modules that depend on Regexp::Grammars, while its predecessor Parse::RecDescent has <a href="http://deps.cpantesters.org/depended-on-by.pl?module=Parse%3A%3ARecDescent" target="_blank">many more dependencies</a>. So I'm wondering why Regexp::Grammars is not more widespread. Some guesses :<br />
<ul>
<li>the learning curve</li>
<li>the dependency on perl 5.10 regexes</li>
<li>the regex engine reentrance problem mentioned above</li>
</ul>
Any other opinions ? <br />
<br />
<br />damihttp://www.blogger.com/profile/05175840149225722194noreply@blogger.com8tag:blogger.com,1999:blog-4836027257696992542.post-18698904102645795522012-02-09T05:46:00.000+01:002012-02-09T05:46:06.749+01:00Plat-forms 2012 : Perl on Amazon Web Services ?A new edition of the Plat-forms programming competition will take place in Berlin, 2nd to 4th of April --- see the <a href="http://www.plat-forms.org/platforms-2012" target="_blank">announcement</a>. <br />
<br />
I enjoyed participating in the 2007 edition (see our <a href="https://www.plat-forms.org/journal-team1" target="_blank">report from that time</a>), so I'm tempted to apply again; currently I'm trying to convince people to join in a team, and to convince my management to support this initiative.<br />
<br />
However, my worry is that this year's competition is targeted at cloud computing and Amazon Web Services (AWS), of which I know nothing ... and the <a href="http://aws.amazon.com/">http://aws.amazon.com/</a> web site, which advertises "developer centers" for various languages, doesn't say a word about Perl. So it seems that quite an investment will be needed for learning how to use this environment and build up appropriate tools for a Perl AWS ecosystem.<br />
<br />
Am I too pessimistic ? Is it much simpler than what I think ? If anybody has information about Perl projects on AWS, please post comments here. Thanks in advance, Laurent D.damihttp://www.blogger.com/profile/05175840149225722194noreply@blogger.com14tag:blogger.com,1999:blog-4836027257696992542.post-77874584676772098522011-08-19T12:41:00.002+02:002011-08-19T14:40:30.234+02:00Beautiful RigaThis year <a href="http://yapceurope.lv/ye2011/">Perl YAPC::EU::2011 </a>conference brought us to Riga : what a nice discovery!
<br />
<br />I barely knew about the existence of this city (apart some vague remembrances of having seen this name when reading Jules Verne's <em><a href="http://fr.wikipedia.org/wiki/Un_drame_en_Livonie">Un drame en Livonie</a></em>, long long time ago). Now I will recommend it to friends.
<br />
<br />Riga has a lot of beautiful buildings, mostly from end of 19th-beginning of 20th century. The <a href="http://www.jugendstils.riga.lv/eng/muzejs">Art Nouveau museum</a> has an interesting film explaining various architectural substyles during that period; then you can easily recognize them when walking in the city. By the way, walking is a pleasure because there are large pedestrian areas through the old town, and several beautiful parks just around that center. There are various churches of different eras and styles, and a tremendous romantic organ in the Dom Cathedral, with a concert every day at noon !
<br />
<br />I discovered interesting composers at the<a href="http://www.choirlatvija.lv/koncerti.asp?pageId=276"> Sacred Music Festival </a>(with high-quality choir, orchestra and soloists); and discovered many interesting painters at the <a href="http://www.vmm.lv/en/lnmm/">Latvian National Museum of Arts</a>.
<br />
<br />So Riga has many advantages of a capital with rich cultural life, but seemingly without too many of its inconveniences : most buildings look fresh and unaffected by pollution, I didn't see any traffic jams, prices are reasonable, etc. Maybe that's the positive aspect of Soviet occupation, that the city was preserved so many years from wild capitalism...
<br />
<br />In short, not only was YAPC a very nice conference, it was also the totally unexpected pleasure of a very interesting touristical exploration (albeit too short).
<br />
<br />Thanks to the YAPC organizers for having brought us there!
<br />damihttp://www.blogger.com/profile/05175840149225722194noreply@blogger.com0tag:blogger.com,1999:blog-4836027257696992542.post-30830967539465705542011-08-16T05:09:00.002+02:002011-08-16T05:42:47.303+02:00about MsOffice::Word::HTML::WriterYesterday I gave a lightning talk on <a href="http://search.cpan.org/dist/MsOffice-Word-HTML-Writer/">MsOffice::Word::HTML::Writer</a>, a module to produce documents for MsWord from HTML content. To anybody interested, here is some more info :
<br />
<br /><ul>
<br /><li>the module only needs Perl, and therefore can run on a server; it doesn't need MsWord to be installed (actually, that's the whole purpose of that module).
<br /></li>
<br /><li>it was written for the needs of Geneva courts of law, where we needed to generate thousands of documents every day, from hundreds of models, with libraries of reusable content parts, with fusion of complex datastructures ... but the resulting docs must be editable in MsWord.
<br /></li></ul>
<br /><p>Other technologies considered, but rejected, were :</p>
<br /><ul>
<br /><li>remote control of an MsWord instance, through a OLE connection. That's what most other courts do, but it only works on a local workstation : you could hardly do the same on a server, first because you would need to install MsOffice, and second because this architecture is not reliable enough : the MsWord instance is a bottleneck, it might break, or it might suddenly put a popup to ask the user for something ... except there is nobody to answer if running on a server. So this approach can be considered if you have a heavy application, deployed on everybody's PC; but not for a Web application.
<br /></li>
<br /><li>generating RTF, using some templating tool : this works on a server, but authoring models can be tricky (esp. it is not obvious to factorize reusable parts).
<br /></li>
<br /><li>generating XML, either in ODF (open format used by OpenOffice), or in OOXML (Microsoft proprietary format) : here the main problem is authoring, because both XML specs are huge, so you really need specialists to produce your models
<br /></li>
<br /><li>generating ODF from <a href="http://search.cpan.org/dist/OpenOffice-OODoc/">http://search.cpan.org/dist/OpenOffice-OODoc/</a> : well, ODF can be read by MsWord, but many features are missing. Besides, OODoc uses a programming approach, not a templating approach, so it's harder to delegate authoring of models to people who are not familiar with Perl.</li></ul>
<br /><p><a href="http://search.cpan.org/dist/MsOffice-Word-HTML-Writer/">MsOffice::Word::HTML::Writer</a> works by assembling HTML content (the main document, the headers/footers, other resources like images or CSS stylesheets), and then packaging the whole thing as a single MIME/multipart file. Model authors just need to know HTML, so it's easy to build an authoring team; and if you have a good templating framework, it's also easy to build a library of reusable content parts.</p>damihttp://www.blogger.com/profile/05175840149225722194noreply@blogger.com6tag:blogger.com,1999:blog-4836027257696992542.post-75393109746252792302011-08-14T20:51:00.002+02:002011-08-14T20:56:45.674+02:00Bad luck with Riga tripI really seem to have bad luck with the trip to Riga for Perl conference YAPC::EU::2011.
<br />
<br />I had booked my flight and hotel several months in advance. A couple of days ago, I received a mail telling that the hotel was overbooked, they had made a mistake, and sent me to another place.
<br />
<br />Now today, my flight from Geneva got delayed by 90 minutes, and I missed the last flight to Riga, so I'm sleeping in Brussels.
<br />
<br />There is a flight to Riga tomorrow morning, so if nothing worse happens, I should still be in time for my talk <a class="moz-txt-link-freetext" href="http://yapceurope.lv/ye2011/talk/3410">http://yapceurope.lv/ye2011/talk/3410</a>.
<br />
<br />
<br />
<br />
<br />
<br />damihttp://www.blogger.com/profile/05175840149225722194noreply@blogger.com1tag:blogger.com,1999:blog-4836027257696992542.post-10945415666406089762011-08-08T22:06:00.002+02:002011-08-08T22:35:23.952+02:00DBIx::DataModel 2.0 is on the wayDBIx::DataModel version 2.0 is on the way.
<br />
<br />It will be a major refactoring, introducing a metaobject layer, choice between single-schema or multi-schema mode, support for table inheritance, for arbitrary join clauses, for bulk updates and deletes; the API has been made more "perlish" (replacing camelCaseMethods by methods_with_underscores). A dev version is already on CPAN; the code seems to be quite stable now, but the distribution is still lacking in documentation and tests, so I'm not sure it will be fully ready before YAPC::EU::2011 ... but at least the slides are ready (see <a href="http://www.slideshare.net/ldami/dbix-datamodel-endetail">http://www.slideshare.net/ldami/dbix-datamodel-endetail</a> if your are interested).
<br />
<br />The last major refactoring was version 1.0 in 2008, and the first published version was 0.10 in 2005, so I seem to be following a 3-year schedule !
<br />
<br />I really hope that DBIx-DataModel will get some more visibility, because it has some features that are quite original in the (big) world of Perl ORMs, and could probably be useful to other people. For those of you who will be in Riga : come at the talk !
<br /><a href="http://yapceurope.lv/ye2011/talk/3411">http://yapceurope.lv/ye2011/talk/3411</a>
<br />
<br />damihttp://www.blogger.com/profile/05175840149225722194noreply@blogger.com0tag:blogger.com,1999:blog-4836027257696992542.post-46242682512874485262011-08-05T15:39:00.002+02:002011-08-05T15:41:35.036+02:00a municipality called PerlI just discovered accidentally that there is a German location called "Perl", close to the Luxemburg border.<br /><br />Maybe a place to consider for the next YAPC ?<br /><br /><a href="http://en.wikipedia.org/wiki/Perl,_Saarland">http://en.wikipedia.org/wiki/Perl,_Saarland</a>damihttp://www.blogger.com/profile/05175840149225722194noreply@blogger.com4tag:blogger.com,1999:blog-4836027257696992542.post-59354771972551190162011-06-10T04:05:00.002+02:002011-06-10T04:37:21.442+02:00Perl dualvar is useful, after allFor many years I had been intrigued by <a href="http://search.cpan.org/perldoc/Scalar::Util">Scalar::Util::dualvar </a>: why would one store both a number and a string within the same variable ?<br /><br />Yesterday I finally found a situation where dualvar was just the perfect answer.I was doing some refactoring in <a href="http://search.cpan.org/perldoc/DBIx::DataModel::Statement">DBIx::DataModel::Statement</a> : each object from this class has a status, that goes through steps "new", "sqlized", "prepared", "executed". Originally his had been coded with plain strings; but the problem with strings is that they are not ordered, so I was considering a change to something like<br /><br /><span style="font-family:courier new;">use constant {NEW => 1, SQLIZED => 2, PREPARED => 3, EXECUTED => 4};</span><br /><br />However such codes are not user-friendly, so when generating error messages I would need to translate them back into strings. Moreover, that change was not backwards compatible. So dualvar came to the rescue :<br /><br /><span style="font-family:courier new;">use constant {</span><br /><span style="font-family:courier new;">NEW => dualvar(1, "new"),</span><br /><span style="font-family:courier new;">SQLIZED => dualvar(2, "sqlized"),</span><br /><span style="font-family:courier new;">PREPARED => dualvar(3, "prepared"),</span><br /><span style="font-family:courier new;">EXECUTED => dualvar(4, "executed"),</span><br /><span style="font-family:courier new;">};</span><br /><br />Now I can write things like<br /><br /><span style="font-family:courier new;">$status >= PREPARED</span><br /><span style="font-family:courier new;">or die "can't do that operation when in state $status";</span>damihttp://www.blogger.com/profile/05175840149225722194noreply@blogger.com1tag:blogger.com,1999:blog-4836027257696992542.post-18952707425906001992011-01-14T19:26:00.004+01:002011-01-14T21:20:23.010+01:00good luck to Plat-forms 2011 Perl teamsI just learned from <a href="http://szabgab.com/blog/2011/01/plat-forms-perl-teams.html">Gabor Szabo's blog</a> that the 2011 <a href="http://www.plat-forms.org/">Plat-forms programming contest </a>is taking place next week, and that 3 excellent Perl teams are participating. This is great news !<br /><br />In my <a href="http://ldami.blogspot.com/2010/08/platforms-20102011-call-for-perl-teams.html">last blog entry </a>(August 2010 ... so long ago!), I mentioned the importance of that contest for the image of Perl outside of our community. Within a couple of months, when the reports will be published, IT specialists from all over the world will get a strong signal that Perl is alive and produces good results.<br /><br />I very much enjoyed participating in the 2007 edition : this was a big stress, but also an enriching experience, not only on the technical aspects, but also on the collaboration skills under strong pressure. Unfortunately I could not register for the 2011 edition, because at work we had to prepare a major organisational change for 01.01.2011, which left us absolutely no time to think of anything else (not even to blog .. see above!).<br /><br />So, all the best for the three Perl teams, thanks for having registered, and I'm sure you will show to the world that our technology is excellent for productivity, conciseness, flexibility and so much more.damihttp://www.blogger.com/profile/05175840149225722194noreply@blogger.com0