• Ary Borenszweig (15/15) Dec 24 2007 Hi all,
• Frits van Bommel (7/23) Dec 25 2007 I always assumed it was so those classes don't need to be directly in

Ary Borenszweig <ary esperanto.org.ar> writes:

Hi all,

Object.mangleof == "C6Object"
Interface.mangleof == "S6object9Interface"

Both are defined in the module object.d

Why Object.mangleof isn't "C6object6Object"? It also happens with 
ClassInfo ("C9ClassInfo").

I'm currently using mangled representations of types to store references 
to other types in Descent, while at the same time respecting the D spec. 
Then I search for a symbol in the hierarchy by parsing the mangled name. 
But because of the inconsistency of "C6Object" I'll have to hardcode 
that value means "Object in module object". Same as for other types in 
module object (in other, user defined modules it doesn't happen).

Is there any reason for this?

Thanks,
Ary

Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

Ary Borenszweig wrote:
 Object.mangleof == "C6Object"
 Interface.mangleof == "S6object9Interface"
 
 Both are defined in the module object.d
 
 Why Object.mangleof isn't "C6object6Object"? It also happens with 
 ClassInfo ("C9ClassInfo").
 
 I'm currently using mangled representations of types to store references 
 to other types in Descent, while at the same time respecting the D spec. 
 Then I search for a symbol in the hierarchy by parsing the mangled name. 
 But because of the inconsistency of "C6Object" I'll have to hardcode 
 that value means "Object in module object". Same as for other types in 
 module object (in other, user defined modules it doesn't happen).
 
 Is there any reason for this?

I always assumed it was so those classes don't need to be directly in 
object.d, allowing them to be in publicly imported modules instead, 
without breaking linking. This way, references to stuff belonging to 
these classes may be emitted without checking to see what module they're 
actually in.

IIRC the same happens for std/typeinfo/*.d, by the way.