Perhaps this could be changed in 1.8.6 itself. Issue a warning if the tag contains a comment.
In 1.8.7, raise an error. jeremy On Tue, Sep 15, 2009 at 7:23 PM, Will Bryant <[email protected]> wrote: > > I'm not arguing that we stick with 1.8.6 for Rails 3.0, I'm pointing > out that there's an upgrade issue that people need to be aware of, > which is what Yehuda was asking for. Kindly re-read my post. > > But since you mention it, I can expect them to at least give an error, > rather than silently losing code. Language providers do not > necessarily have the burden of making everything that used to work > continue to work (although some have chosen to do so), but they are > generally expected to change things in a way that lets people at least > notice the problems promptly. > > > On Wed, Sep 16, 2009 at 8:49 AM, Adam Milligan > <[email protected]> wrote: >> >> This comment example is invalid ERB, and is relatively clearly >> documented as such. You can't reasonably expect language providers to >> support behavior that they've explicitly declared as invalid, and you >> can't reasonably expect framework providers to stick with a language >> version because you've chosen to depend on a particular incarnation of >> undefined behavior. This is directly akin to depending on the order >> of the contents of a hash, or referencing values in freed memory. >> There are reasonable reasons to want Rails 3.0 to work on Ruby 1.8.6, >> but this isn't one of them. >> >> Incidentally, the behavior in at least some versions of 1.8.6 is >> consistent with 1.8.7. >> >> On Sep 13, 5:23 am, Will Bryant <[email protected]> wrote: >>> On Wed, Sep 9, 2009 at 7:17 PM, Yehuda Katz <[email protected]> wrote: >>> > Finally, Ruby 1.8.7 does not appear to provide backward-compatibility >>> > issues. For instance, WePlay, which has a significant, complex app, had a >>> > lot of trouble porting their app to Ruby 1.9, but basically zero problems >>> > with Ruby 1.8.7. The few issues that people did have were rapidly and >>> > diligently resolved by the Ruby team. Do you have any reason to believe >>> > otherwise? >>> >>> There is that ERB comment issue, whereby it turns out (according to >>> the official documentation) that we were not actually allowed to write >>> things like: >>> >>> <% elsif customer.oddball? # we get lots of these guys %> >>> >>> which is pretty widely used and worked perfectly just fine most or all >>> of the way through the 1.8.6 series but doesn't on 1.8.7 >>> (seehttp://www.ruby-forum.com/topic/154835andhttps://rails.lighthouseapp.com/projects/8994/tickets/955-ruby-187-an...). >>> >>> This is a really nasty one because, really, there's no reason why this >>> shouldn't be made to work, and when it stops working, it doesn't >>> break.... you just lose a whole big chunk of output from your views. >>> A bit silent and nasty for many of us. >>> >>> The Ruby guys don't seem to be inclined to change it back, so unless >>> one already has full test coverage for each and every case/path in >>> every one of your views files, this is something important to scan for >>> when upgrading to 1.8.7. >>> >>> You could get an approximate test with just grep if you're careful >>> about the conditions (for example, <%# this is a legitimate ERB >>> comment %> but <% # this isn't %>, and be careful about multiple >>> blocks on one line), so if you are moving the whole team to 1.8.7 and >>> so just need to do a once-over pass, that's probably fine. >>> >>> But that will tend to produce false alarms, for example if you have >>> other uses of hashes on the same line, such as <% s = >>> '/test.html#anchor' %>, so it's not much help if you want an automated >>> test to run in continuous integration or need to audit a large number >>> of views. I'm knocking up a bit of code to do it properly using >>> ruby-parser, if people are interested I'll sort out a good way to >>> package and release it. >> > >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
