On Sunday, 20 August 2017 at 01:33:00 UTC, Nicholas Wilson wrote:
I'm not quite sure how this would lead to a loss of modularity?
Not sure if modularity is exactly the right word. The problem would be akin to extension methods in C#, or even a useful set of UFC's in D.
So, imagine you decide you need DateTime.LastWeek() or something similar. This turns out to be something you end up needing in most of your projects. So first of all, you're now required to start bringing this file into every project you work on. This is already annoying. Then, one day, you decide you also need DateTime.FortnightAgo(). So you add it to the file, except that all the other versions are now out of sync. You think, maybe I should have made a repository!? First of all, too late. Second, you now have to clone a repo into all your new projects instead of dragging and dropping a file, and update the repo every time you want to work on the project in case anything changed. At this point, any reasonable person would be frustrated....but wait...you also need some extensions for Math as well, which are not necessarily related to the extensions for DateTime. I suppose you could start throwing together your own small support library with all of these things in there... But wait...some of the extensions are platform specific *facepalm*. So eventually, you end up with a chart like this[1] describing which of these libs are in each of your projects.
The catch is, that a lot of the time, the things you make are these extensions for are so ubiquitous that they should probably just be included in the language, or standard library. An easy example is the million different variations of C++ "thread", "mutex" and "hashtable" that were built while the C++ community took a coffee break from 1998 to 2011 ;)
I think I've painted the picture sufficiently at this point. [1] http://i.imgur.com/cQxxQJs.png
