[Mono-dev] Environment.GetFolderPath() behaviour inconsistent with .NET

[Stifu]

I understand your points, Miguel, but it sucks not to be able to be
consistent / compatible with .NET here.
I know it's not possible to get numbers, but how many Mono OSX apps do you
think currently rely on this feature vs how many Silverlight / .NET apps
could benefit from this change? And it's not just about Silverlight
compatibility, but about adopting a predictable and now documented behavior.
Keeping in mind that .NET in general has many more users than Mono does, I
do not understand why the Mono team is sometimes reluctant to break backward
compatibility with older Mono versions.

And you don't have to break compatibility brutally, you can do it in a soft
way. If you release Mono 3.0 but clearly state in the release notes to watch
out about this, I don't think there is that much harm done. You could even
make the new behavior opt in at first, warn programmers about the new
behavior, and after a year or two, make the new behavior the default.

I'm not personally affected by this issue, by the way, but I value
consistent or optimal solutions over "bad" decisions for the sake of
backward compatibility. Look at Java, doing everything toward backward
compatibility (like the way they implemented generics)... I think this is
short sighted. Several years later, it doesn't matter anymore whether they'd
have broken compatibility with previous versions or not. What matters now is
that we have an inferior product because of their decision. It may have
looked like this may have saved them some users back then, but what about
now?

The way I see it, it's a choice between "pissing off some people a lot now
and be done with it" vs "pissing off some people for eternity". I'd go for
choice one. I reckon I'm a bit of an Utopian.

End of rant, sorry if it came off as annoying. :)


Miguel de Icaza-6 wrote:
> 
> Hello,
> 
> So is there a way to get a path to the Documents folder in OSX
> symbolically
>> without hard-coding it?
>>
> 
> Hard-code it, as it seems that OSX goes down the path of hardcoding HOME +
> Documents as the directory, and then provides API to internationalize the
> result.
> 
> Looking briefly at the bug reports, it appears that the original .NET
>> specification intended for that special folder enum to point to the
>> Documents directory, not the user's home folder. So, and correct me if I
>> am
>> wrong, it does appear that the original implementation decision was not
>> in
>> line with the .NET specification.
>>
> 
> It was when Mono was developed in 2001.
> 
> Nevertheless, I am not moving my application from Silverlight to Mono, I'm
>> trying to develop an application that supports both simultaneously
>> (something that it appears should be possible since one is supposed to be
>> a
>> superset of the other other).
>>
> 
> I suggest you probe at runtime the system and decide the code path you
> take.
> 
> If Mono has a way of getting the Documents folder without hardcoding it,
> I'd
>> be happy to use it in my specific application. I just don't want to end
>> up
>> in a situation where Mono decides to fix this in a future version and I
>> end
>> up getting a directory of the form //Users/Username/Documents/Documents/.
>>
> 
> That is precisely the reason we are not going to change the existing
> behavior, so existing code does not break.
> 
> Miguel
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 

--
View this message in context: http://mono.1490590.n4.nabble.com/Environment-GetFolderPath-behaviour-inconsistent-with-NET-tp3341537p3753588.html
Sent from the Mono - Dev mailing list archive at Nabble.com.