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.
