I strongly agree with JLee here
"code that runs stable once, should run stable in future (while nothing has
changed in the environment)"
Improvements and performance enhancements are always welcomed but they
should not break existing code. Google breaks code all the time, it's true,
and it's horrible to handle with when your're building for multiple Android
versions. This kind of behavior reminds me of html/js where you need a
piece of code for each browser available - it's ugly and counterproductive.
Obviously, sometimes the changes are so deep that they need to break code -
these should be strongly pointed out. But an effort should always be made
to maintain compatibility (keeping an older method or class for example).
On 27 August 2013 03:20, SRI wrote:
> Hi,
>
> Not to make you undo what you have done, but is this the right
> decision?
>
> Progress comes with a cost, if someone wants to upgrade to use
> the latest software and expects it to not break older programs, they can
> just not upgrade. Microsoft spent enormous amount of time/cost ensuring
> backward compatibility. Apple/Facebook break thinks when newer software is
> released. Which way does Xamarin want to go? For me as long as the change
> is an improvement, it is better to improve rather than be restricted
> because of backward compatibility.
>
> Most good programmers, hate rework and they will never like to
> redo what was working perfectly and they will never approve even something
> which may be beneficial to a large number of developers if it requires
> rework. Hence doing things based on Programmer desire may lead us on the
> wrong path.
>
> 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??disable it. Sorry for recommending unnecessary work to ensure
> backward compatibility. This way of working is going to be hell for all
> programmers, if by default we are not implementing optimization since they
> have now to read documentation to understand all these flags and it
> increases everyone's work.
>
> Backward compatibility is a beast and ensuring backward
> compatibility may be an incorrect decision from a
> time/cost/improvement/developer point of view.
>
> Just my 2 cents.
>
>
>
>
> On Tue, Aug 27, 2013 at 3:35 AM, Jonathan Pryor wrote:
>
>> On Aug 17, 2013, at 5:19 PM, JLee wrote:
>> > Jonathan Pryor-2 wrote
>> >> 1. I revert the optimization. <...>
>> >> 2. We document this somewhere, and say "Don't Do That" <...>
>> >
>> > What's about:
>> > 1. revent the "optimization" until
>> > 3. We've found another solution
>> > ?
>>
>> That amounts to "revert, and don't bother discussing the tradeoffs." I
>> was attempting to provide the tradeoffs in an effort to spark discussion.
>> It would seem that a reduced GREF count is immaterial; it breaks code, and
>> thus should be reverted, period.
>>
>> Fair enough. Done. The next 4.8.2 alpha will revert this change.
>>
>> - Jon
>>
>> ___
>> Monodroid mailing list
>> Monodroid@lists.ximian.com
>>
>> UNSUBSCRIBE INFORMATION:
>> http://lists.ximian.com/mailman/listinfo/monodroid
>>
>
>
>
> --
> Sridharan Srinivasan
> Alias Sri
> Ph:(65)98255785/(65)63922439
> www.arshu.com
>
> ___
> Monodroid mailing list
> Monodroid@lists.ximian.com
>
> UNSUBSCRIBE INFORMATION:
> http://lists.ximian.com/mailman/listinfo/monodroid
>
>
--
Gonçalo Oliveira
___
Monodroid mailing list
Monodroid@lists.ximian.com
UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
