On Mon, 07 May 2012 13:34:49 -0400, Andrew Wiley
<wiley.andre...@gmail.com> wrote:
On Mon, May 7, 2012 at 12:21 PM, Steven Schveighoffer
<schvei...@yahoo.com>wrote:
I agree that's the case with the current object/linker model. Something
that puts inferred properties into the object file needs a new model,
one
which does not blindly link code that wasn't compiled from the same
sources.
Then all you've done is to make attributes the author can't control part
of
the API, which will force library users to recompile their code more
often
for non-obvious reasons. Avoiding that is one of the points of shared
libraries.
Shared library entry points have to have *no* inference. Otherwise you
could inadvertently change the public API without explicitly tagging it.
I believe in D, shared library entry points have to be tagged with export.
Not to mention, shared libraries on a certain platform usually have to be
linked by the platform's linker. So we can't exactly overtake that aspect
with a new model.
I think we're actually talking about different contexts. I'm speaking in
the context of shared libraries, where I think the API needs to be
exactly
what the author requests and nothing more. With object files, static
libraries, and static linking, I agree that this sort of thing could work
and wouldn't cause the same problems because it's impossible to swap the
library code without recompiling/relinking the entire program.
OK, that makes sense, I think you are right, we were talking about two
different pieces of the model.
-Steve
