It makes me sick!

[FoxyBrown via Digitalmars-d-learn]

On Friday, 28 July 2017 at 01:10:03 UTC, Mike Parker wrote:
> On Friday, 28 July 2017 at 00:28:52 UTC, FoxyBrown wrote:
>
>> You are not being very logical.
>>
>> The zip file as N files in it. No matter what those files are, 
>> it should be a closed system. That is, if I insert or add(not 
>> replace) M file to the directory structure it should not break 
>> D, period!
>
> That's *not* what happened here. Jonathan explained it quite 
> well. std.datetime was refactored into a package, its contents 
> split into new modules. When you import a module foo, dmd looks 
> for:
>
> 1. foo.di
> 2. foo.d
> 3. foo/package.d
>
> When it finds one, it stops looking. It's not an error for all 
> three to exist. Your error came because it found 
> std/datetime.d, but you linked to a library that included 
> symbols for std/datatetime/package.d. It's not the compiler's 
> responsibility to error in that case. It's your responsibility 
> to properly install.
>

Sorry, wrong.

>>
>> Why? Because NO file in the zip should be referencing any file 
>> not in the zip unless it is designed to behave that way(e.g., 
>> an external lib or whatever).
>>
>> If an old external program is referencing a file in dmd2 that 
>> isn't in the new zip it should err.
>>
>> Why? Because suppose you have an old program that references 
>> some old file in dmd2 dir and you upgrade dmd2 by extracting 
>> the zip. The program MAY still work and use broke 
>> functionality that will go undetected but be harmful.
>>
>> Why? Because dmd.exe is reference a file it shouldn't and it 
>> should know it shouldn't yet it does so anyways. It really has 
>> nothing to do with the file being in the dir but that dmd is 
>> being stupid because no one bothered to sanity checks because 
>> they are too lazy/think it's irrelevant because it doesn't 
>> effect them.
>
> That's unreasonable.

Nope, your unreasonable expecting the end user to clean up the 
mess "you" leave.

>>
>> I should be able to put any extra files anywhere in the dmd2 
>> dir structure and it should NOT break dmd.
>
> There are numerous applications out there that can break if you 
> simply overwrite a directory with a newer version of the app. 
> DMD is not alone with this. You should always delete the 
> directory first. It's precisely why the compiler does so.

Nope. Virtually all apps, at least on windows, work fine if you 
replace their contents with new versions. Generally, only 
generated files such as settings and such could break the apps... 
but this is not the problem here.


If dmd breaks in strange and unpredictable ways IT IS DMD's 
fault! No exceptions, no matter what you believe, what you say, 
what lawyer you pay to create a law for you to make you think you 
are legally correct! You can make any claim you want like: "The 
end user should install in to a clean dir so that DMD doesn't get 
confused and load a module that doesn't actually have any 
implementation" but that's just your opinion. At the end of the 
day it only makes you and dmd look bad when it doesn't work 
because of some lame minor issue that could be easily fixed. It 
suggests laziness["Oh, there's a fix but I'm too lazy to add 
it"], arrogance["Oh, it's the end users fault, let them deal with 
it"], and a bit of ignorance.

In the long run, mentalities like yours are hurting D rather than 
helping it. Sure, you might contribute significantly to D's 
infrastructure, but if no one uses because there are so many 
"insignificant" issues then you've just wasted an significant 
portion of your life for absolutely nothing.

So, I'd suggest you rethink your position and the nearsighted 
rhetoric that you use. You can keep the mentality of kicking the 
can down the road and blaming the end user but it will ultimately 
get you no where.