On Fri, Sep 30, 2011 at 09:28:06AM -0400, Michael Peters wrote: > On 09/29/2011 07:20 PM, David Golden wrote: > >> What it doesn't solve, though, is the ability for people to use old >> code with a newer Perl without the risk of breakage/fixage when then >> upgrade. > > What if everything is just advisory? Meaning, whatever syntax we pick to > declare the version we make it mean (ignoring other issues like > threads/no-threads, architecture, etc for now): > > I've tested this code on this version and I know it works. If this is > a newer version of perl with different semantics for something I'm > using please bail out and let me know ASAP. "Let me know" could also > mean teaching my how to install the older version of Perl I need > (perlbrew). > >> Personally, I favor a tough love policy where breakage is OK >> and no-one is forced to upgrade, but many hold the exact opposite >> point of view. > > Speaking as a lurker, I agree. When I saw Jesse give his talk at > YAPC::NA I was pretty excited. But the more I thought about it the more > unlikely (if not impossible) it seems. It seems like these kinds of > multi-version syntax and multi-version semantics will make the core > harder to work with, not easier. This will put more pressure on people > who can actually do the work and less people will be able to jump in and > help. The exact opposite of what was intended. I'm looking at this from the POV of the programmer. The multi-version syntax certainly has its benefits, although I can see some drawbacks as well. It's the multi-version semantics that worry me. Yes, often it's useful that if I stick "use 5.X" on the code, I get 5.X semantics. But often, code I write has to interact with other pieces of code, possibly written be other people, and written when other version of Perl were in vogue. Often enough, it's far more important to be able to say "behave in the same way as the rest of the code", instead of "pick a version, any version, and behave like that forever". AbigailThread Previous | Thread Next