On Fri, March 9, 2012 12:33, Jon Leighton wrote: > On 09/03/12 15:56, Steve Klabnik wrote: >> Rails 3.3: scaffolding considered deprecated. Add >> deprecation warnings >> to all scaffolding stuff. >> Rilas 3.4: yep, still deprecated >> Rails 4.0: scaffolding removed. > > This example does not demonstrate the problem I am > trying to solve. The problem is when behaviour changes, > not when stuff gets removed. > > Suppose rails has a #lol method. Currently #lol return > "lol". We want to make it return "omg". How do we know > whether a user is relying on the current return value of > "lol", in order to give them a deprecation warning? >
If you actually do that then you have in fact deprecated lol (old) and replaced it with lol (new) and you have NOT provided a deprecation/update path. Following SemVer that automatically forces a major number increment. Let us consider how methods are actually used. If lol (new) extends the signature in addition to changing the behaviour then the expected behaviour may be specified. If the extended signature is used then return "omg", otherwise return "lol" + deprecation warning. However, in this case I think it best simply to deprecate the lol method and use a different name for the new one. Letters are cheap, labour is not. Why create busy work? -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:[email protected] Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 -- 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.
