No, I do not know of any case and I'm not proposing to break compatibility, I love the backwards compatibility and the "web2py" way of doing things.
I was just wondering if by chance it might not be an issue to think about. There is no way to measure how far the maintenance of compatibility could lead to API conflicts or anything like that. Or even to implement new and different ways of writing the same things (only syntax changes as you said) I saw that kind of thing in Pylons when I needed to move from 0.9.x to 1.0 (in a strange way using an IF/try statement for conditional imports), as I saw that in web.config for .net framework (the hell of dll version control) as I saw this in PHP.ini file when moving to 5.2 but, nevermind about that, random wonder 2010/10/28 mdipierro <[email protected]> > I do not think we should ever break backward compatibility in order to > change syntax (because here there is nothing more that syntax at > stake, not functionality). > > Different people have different preferences. > > Can you think of any case where backward compatibility has prevented > us form adding a read feature? > > Massimo > > > On Oct 27, 9:27 pm, Bruno Rocha <[email protected]> wrote: > > > Morover changing it (even > > > if it were possible) would be a change in backward compatibility. > > > > Speaking of backwards compatibility, sometimes I see some users are > tending > > more to have new features and design changes than maintaining backward > > compatibility > > > > I think backwards compatibility is one of the most important things in > > web2py, and this gives us security, that matters at all. > > > > But perhaps one day will be necessary to have the option of working in > > different ways to take advantage of the rapidly evolving concepts of web > > development. > > > > It would be a bad idea to have a way to configure the compatibility mode? > > > > At some per application startup script or config: (could be in > > models/0.py?) > > > > BACKWARDS_COMPATIBILITY = True | False > > > > Depending on this configuration could use the web2py new > > implementations/changes or keeping compatibility > > > > I know this may be more complicated than I imagine, but can be a way out > in > > the future as well as Python did in reverse way with "from __future__ > import > > *" > > > > just wondering.... > -- http://rochacbruno.com.br
