@SRI it's a question of definition (and point of view), what improvement/progress is, and if refactoring code is the "cost" we have to accept for it.
I have to manage a huge project with a relativ high level of complexity. Refactoring code, depending on what has to be refactored, can cost me hours/days. Time, that I don't have. Time, that I don't get payed off for. For you, backward-compatibility is beast, for me, it's refactoring. > For me as long as the change is an improvement, it is better to improve > rather than be restricted because of backward compatibility. Is it really an improvement, when accessing a parameter of an method leads you in a SIGSEGV? Isn't this something, that has to work in general? > Rather than removing this optimization, Is it possible to create a static > flag at class level to skip/enable this optimization and by default it can > skip??enable?? and in case it is required then developers can enable For me, it would be acceptable, if I could get backward-compatibility by setting a flag. A optimization could enabled by be default to ensure the progress of mono. (of cours we only need a switch like this if an improvement leads into problems with backward-compatibility). nevertheless, I think in case of m4a, code-compatibility should primarily relate to the api level of android and should offer the same backward-compatibility-level as android does. Lee -- View this message in context: http://mono-for-android.1047100.n5.nabble.com/Since-4-8-0-1-SIGSEGV-on-accessing-IEditable-from-ITextWatcher-s-AfterTextChange-tp5713467p5713500.html Sent from the Mono for Android mailing list archive at Nabble.com. _______________________________________________ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
