name resolution in module imports

["Jérôme M. Berger"]

Jon Perez wrote:
> In the Youtube tech talk by Andrei (
> http://www.youtube.com/watch?v=RlVpPstLPEc ), the audience member raises a
> point at @34:20 about how code that does not qualify a module in a function
> call, and just relies on function signatures to know which module this belongs
> to may break if a newer version of the modules it imports suddenly puts into
> the namespace a new function with the same signature as another module.
> 
> Andrei argues that this is a deliberate trade-off.  I think this is fine in a
> statically linked library context because the binaries you ship never break
> anyway.  But what about in a dynamically linked library scenario?
> 
> game.exe links to module1.dll and module2.dll and calls drawcircle(int,int)
> which is not defined in module2 right now, but what if module2.dll gets
> updated in the future and suddenly introduces a drawcirlce(int,int) as well?
> Now game.exe will throw a runtime error.
> 
	What Andrei describes is only valid at the source code level. Once
the program is compiled, it doesn't use "drawcircle(int,int)" to
identify the function, instead it uses the mangled name which
includes the module name anyway.

		Jerome

PS: BTW, this has nothing to do with static vs dynamic linking. If
you link statically against module1 and module2 and they both
contain a function named drawcircle(int,int) then a file may still
call the unqualified drawcircle if it imports only one of the modules.
-- 
mailto:jeberger at free.fr
http://jeberger.free.fr
Jabber: jeberger at jabber.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20101001/d8464779/attachment-0001.pgp>