Re: Living with smart match breakage
gvim writes: The original request was for a pointer to any definitive list of edge cases for smart match breakage, There isn't such a list -- its experimental nature means anything might change. P5P doesn't have consensus, and no decision has been made on what's going to happen. There are some on P5P suggesting that smartmatch is so broken it should be removed entirely. Personally I liked RJBS's proposal, but not everybody else did. Smylers -- Stop drug companies hiding negative research results. Sign the AllTrials petition to get all clinical research results published. Read more: http://www.alltrials.net/blog/the-alltrials-campaign/
Re: Living with smart match breakage
On 2013-06-14 09:11, Smylers wrote: There isn't such a list -- its experimental nature means anything might change. P5P doesn't have consensus, and no decision has been made on what's going to happen. There are some on P5P suggesting that smartmatch is so broken it should be removed entirely. That was the impression I got from the sparse details in the 5.18 announcement and what worried me more than anything else was precisely that uncertainty. That there is no consensus that at least some of smart match and thus, given/when, can be considered non-experimental (and thus safe to use in production) means that a lot of application and library code may have to be rewritten at some point but nobody is really able to definitively determine what the scale of that risk is. Certainly we can continue to declare use experimental and things will continue to work but that is a risky strategy.
Re: Living with smart match breakage
A lot of? Are people really using this in production code now? Sent from my iPhone On 14 Jun 2013, at 09:32, jason ja...@ukfsn.org wrote: On 2013-06-14 09:11, Smylers wrote: There isn't such a list -- its experimental nature means anything might change. P5P doesn't have consensus, and no decision has been made on what's going to happen. There are some on P5P suggesting that smartmatch is so broken it should be removed entirely. That was the impression I got from the sparse details in the 5.18 announcement and what worried me more than anything else was precisely that uncertainty. That there is no consensus that at least some of smart match and thus, given/when, can be considered non-experimental (and thus safe to use in production) means that a lot of application and library code may have to be rewritten at some point but nobody is really able to definitively determine what the scale of that risk is. Certainly we can continue to declare use experimental and things will continue to work but that is a risky strategy.
Re: Living with smart match breakage
Presumably CPAN testing of a blead perl with smartmatch removed/deprecated could pick that up pretty quickly. I mean I have under-used experimental cpan modules that have some test failures, but if they suddenly started throwing do not compile errors[1], even I would pick them up. [1] Not that I use many of the newer core features, occasionally I have to account for some of my $work code having to work on 5.8. On 14/06/2013, at 6:32 PM, jason wrote: On 2013-06-14 09:11, Smylers wrote: There isn't such a list -- its experimental nature means anything might change. P5P doesn't have consensus, and no decision has been made on what's going to happen. There are some on P5P suggesting that smartmatch is so broken it should be removed entirely. That was the impression I got from the sparse details in the 5.18 announcement and what worried me more than anything else was precisely that uncertainty. That there is no consensus that at least some of smart match and thus, given/when, can be considered non-experimental (and thus safe to use in production) means that a lot of application and library code may have to be rewritten at some point but nobody is really able to definitively determine what the scale of that risk is. Certainly we can continue to declare use experimental and things will continue to work but that is a risky strategy.
Re: Living with smart match breakage
On 14 Jun 2013, at 10:26, Kieren Diment dim...@gmail.com wrote: [1] Not that I use many of the newer core features, occasionally I have to account for some of my $work code having to work on 5.8. I don't use smart match precisely because it doesn't feel intuitive and I have enough to worry about without having to memorise yet another table of results, some of which are surprising. I suspect most people are in the same boat, but the darkpan argument always gets trotted out in these cases. The solution you present of a Perl release that fails compile would be nice though. Perhaps with a switch in a new release of Perl? James
Re: Living with smart match breakage
On Fri, Jun 14, 2013 at 09:32:00AM +0100, jason wrote: On 2013-06-14 09:11, Smylers wrote: There isn't such a list -- its experimental nature means anything might change. P5P doesn't have consensus, and no decision has been made on what's going to happen. There are some on P5P suggesting that smartmatch is so broken it should be removed entirely. That there is no consensus that at least some of smart match and thus, given/when, can be considered non-experimental (and thus safe to use in production) means that a lot of application and library code may have to be rewritten at some point but nobody is really able to definitively determine what the scale of that risk is. I ASSume that before it's removed, someone will make sure that there's something on the CPAN that will be a drop-in replacement in almost all cases. IIRC Zefram worked some dark magic to let you define custom operators using XS. -- David Cantrell | semi-evolved ape-thing There are many different types of sausages. The best are from the north of England. The wurst are from Germany. -- seen in alt.2eggs...
Re: Living with smart match breakage
On Fri, 2013-06-14 at 19:26 +1000, Kieren Diment wrote: Presumably CPAN testing of a blead perl with smartmatch removed/deprecated could pick that up pretty quickly. Automated CPAN testing occurs on new releases of modules only doesn't it or is there comprehensive testing of every current release on CPAN when a new perl is being prepared for release? Even if you catch everything in CPAN that doesn't address the risk for in house libraries which is an issue for many of those using perl in production and doesn't address application code using smart match or given/when. My point was more about the difficulty this uncertainty causes in assessing the risk that it will be necessary to rewrite libraries and applications.
Re: Living with smart match breakage
On Fri, Jun 14, 2013 at 02:13:00PM +0100, Jason Clifford wrote: On Fri, 2013-06-14 at 19:26 +1000, Kieren Diment wrote: Presumably CPAN testing of a blead perl with smartmatch removed/deprecated could pick that up pretty quickly. Automated CPAN testing occurs on new releases of modules only doesn't it or is there comprehensive testing of every current release on CPAN when a new perl is being prepared for release? For several years now Andreas König has been smoking existing CPAN modules using development versions of perl. He's found (and we've fixed) a lot of problems before anyone ever realised that they existed. Nicholas Clark
Re: Living with smart match breakage
On Fri, Jun 14, 2013 at 02:13:00PM +0100, Jason Clifford wrote: On Fri, 2013-06-14 at 19:26 +1000, Kieren Diment wrote: Presumably CPAN testing of a blead perl with smartmatch removed/deprecated could pick that up pretty quickly. Automated CPAN testing occurs on new releases of modules only doesn't it or is there comprehensive testing of every current release on CPAN when a new perl is being prepared for release? There are a few people who run all of the CPAN past new perl releases these days, especially perl release candidates. -- David Cantrell | even more awesome than a panda-fur coat I think the most difficult moment that anyone could face is seeing their domestic servants, whether maid or drivers, run away -- Abdul Rahman Al-Sheikh, writing on 25 Jan 2004 at http://archive.arabnews.com/?article=38558
Re: Living with smart match breakage
On Fri, Jun 14, 2013 at 07:26:39PM +1000, Kieren Diment wrote: Presumably CPAN testing of a blead perl with smartmatch removed/deprecated could pick that up pretty quickly. I mean I have under-used experimental cpan modules that have some test failures, but if they suddenly started throwing do not compile errors[1], even I would pick them up. [1] Not that I use many of the newer core features, occasionally I have to account for some of my $work code having to work on 5.8. I've placed the comment When we move away from 5.8, perhaps replace this with given/when several times at $WORK. It took us quite a number of years to move away from 5.8.5 (and we're still trailing a couple of releases). But now, it won't make sense to use given/when, if it may change in the future. But someone is going to use given/when at some point in time, putting another hurdle for an upgrade to 5.18 or beyond (whenever that may be). (If you hire more than a handful of new devs each month, someone will not have gotten the memo). Turning on warnings for using a construct more than *five* years after it was introduced doesn't make Perl win any brownie points for an outsider (yes, I understand the reasons, and no, I don't have a better solution). Abigail
Re: Living with smart match breakage
On Friday, 14 June 2013 at 07:51, David Cantrell wrote: IIRC Zefram worked some dark magic to let you define custom operators using XS. Interesting. Quick, someone write a module that lets you hook this in Perl space and then let the experimentation begin. After all, it doesn't have to be efficient when we're prototyping, just able to iterate through stuff quickly. Even if we don't come up with a good set of behaviours there has to be some awesome possibilities for Acme modules in there. Mark.
Re: Living with smart match breakage
On Friday 14 Jun 2013 16:29:23 Abigail wrote: (If you hire more than a handful of new devs each month, someone will not have gotten the memo). Some people will think they /have/ got the memo because the feature's been written about in the Camel book, Modern Perl, and no doubt other books too.
Re: Living with smart match breakage
Putting my hand up as one of the idiots... I've been using given/when for ages. My impression was that it was announced as a new feature, yay perl has a case statement (only better) at last, and I piled in. Maybe I passed danger signals on the way, but not consciously. Lots of books/presentations promoted it, and I don't remember the small print. Marking it as experimental now seems to me to be rewriting history, what we wish we'd said at the time. The 5.10 perlsyn page for example does not give any warnings at all. I defend the option to change the language and remove broken stuff, but I'm slightly peeved to be labelled a bleeding-edge cowboy for using something that has been promoted widely for years. A quote from the 4th edition Camel, at the end of *5 pages* of discussion of given/when: We still consider some of the darker corners of given and when to be experimental, but please be assured that in practice most of your switch statements are likely to be based on simple string or number matches, and these will always work the way you expect. I want my matches - just about all of them simple string or number matches - to always work, please. Finally, the OP mentioned convoluted boilerplate and was offered no warnings 'experimental::smartmatch'; # or use experimental 'smartmatch'; If you think that's memorable and quick to type, your brain and fingers must move faster than mine, or you program in an IDE. By the time you've knocked that lot out you might as well type a bunch of elsifs anyway. Slightly more annoyed than I expected to be at the beginning of this rant, Gordon On 14/06/2013 16:09, Graeme Hewson wrote: On Friday 14 Jun 2013 16:29:23 Abigail wrote: (If you hire more than a handful of new devs each month, someone will not have gotten the memo). Some people will think they /have/ got the memo because the feature's been written about in the Camel book, Modern Perl, and no doubt other books too.
