Thanks, Nathan, that's a good way to put it. All people need to do is set a config option to make existing apps work.
The challenge is getting 100% of upgrading users to find this info. We'd need to highlight this in a README, in the docs, and answer tech support questions on this. And there may still users who miss it. Yes, it might be their own fault, but that's still a dent in our rep for those users. (we can balance this against tech support for new users who should see macro errors but don't. pretty minimal to date). For other similar issues (e.g. allowing set's to set null's) we've made the config default to old behavior. Minor though this seems, it's enough of an exception I'd like to hear from other committers before giving up our goal of 100% "drop-in" replacement. WILL On 3/21/06, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > If i may be forgiven one last push... :) > > Let's keep the story straight--you wouldn't have to edit the old apps > to make them work with 1.5. You just have to set the config property, > not really a great burden. We could even make the message with the > thrown exception point out the new config property, so that those who > don't read change logs or release notes will have no problem figuring > out what's going on. > > On 3/21/06, Will Glass-Husain <[EMAIL PROTECTED]> wrote: > > I feel strongly about this. > > > > I've personally got hundreds of templates in production and support > users > > with hundreds more. Say 5% of those templates have this error. (It's > not > > hard to make -- note that the Velocity test suite for Anakia contains > this > > error). All of a sudden I have tens of templates, scattered all over > the > > place that suddenly cause errors. All of those apps work right now- why > do > > I want them to fail? Anything that requires me to edit old apps to make > > Velocity 1.5 work is not backwards compatible. (and will retard > adoption of > > 1.5). > > > > It would have been nicer if this had always generated an error. For new > > apps this is better. But for old apps it is actively harmful to change > > this. So let's make this a config option and turn it on by default for > 2.0 > > . > > > > WILL > > > > On 3/21/06, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > > > > > On 3/21/06, Will Glass-Husain <[EMAIL PROTECTED]> wrote: > > > > I'm starting to agree with you, Llwellyn. Though I don't think we > > > should > > > > change the behavior of the templates for existing users. > > > > > > even if the behavior is buggy/broken? it's not like the extra or > > > missing arguments were doing anything functionally. throwing an > > > exception, however, will add functionality (as Malcom demonstrated. > > > we already warned that their macro call was broken in the logs, i > > > think it is fair to escalate that to an exception, especially if we > > > provide a config option to log instead of throw an exception. > > > > > > of course, if you feel strongly about this, i won't -1 a log-only > > > default, and i'll let them that do the work implement it the way they > > > want :). it's just my opinion; i won't be dogmatic on it. :) > > > > > > > > > > > WILL > > > > > > > > On 3/21/06, Llewellyn Falco <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > Personally, i feel that templates whose macro calls don't match > up > > > to > > > > > > the macro definitions are *already* broken. > > > > > > > > > > this is my general thought on the whole thing too. > > > > > > > > > > and as we deal in financial transactions, I take a general view of > > > > > it is better not to show something than to show something wrong. > > > > > > > > > > however, I can understand that in an entertainment situation you > might > > > > > have > > > > > the exact opposite view. > > > > > again though, I think this goes back to a 2 modes of running. > > > > > > > > > > development - always halt on errors - someone's there to fix them. > > > > > deployment - do the best you can - log what goes wrong > > > > > > > > > > and see a setting much more in this idea. > > > > > > > > > > > > > > > > > > > > btw: this is also why I always develop with the UberspectTestImpl > and > > > > > rather > > > > > think that it should be default Uberspect, while currently it is > only > > > in > > > > > the > > > > > test classes. > > > > > > > > > > Llewellyn. > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > -- > > > > Forio Business Simulations > > > > > > > > Will Glass-Husain > > > > [EMAIL PROTECTED] > > > > www.forio.com > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Forio Business Simulations > > > > Will Glass-Husain > > [EMAIL PROTECTED] > > www.forio.com > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com
