Opened 7 years ago

#345 new defect

Necessary refactoring of mangling methods in

Reported by: ksmith Owned by: somebody
Priority: major Milestone: wishlist
Component: Code Generation Keywords:


Note: Using branch gsoc-kurt, which has merged with cython-unstable.

Currently it is not possible to control the name mangling with subclasses as required for UtilityCode to work properly. The NonManglingModuleScope class defined in is a workaround; it would be better to refactor the Scope.mangle methods (and related mangling methods) to something like

def mangle(self, ...):

Which gives us inversion of control.

Some more thoughts excepted from email:

> Turns out the UtilityCode.NonManglingModuleScope implementation of
> mangle() doesn't get called at the right times when parsing/defining
> the cython.array implementation.
> When cython.array is parsed, it gets a CClassScope as it should, and
> the CClassScope's outer_scope is, correctly, a NonManglingModuleScope
> instance.  When mangle() is called, it uses the default
> Scope.mangle(), but it should use outer_scope.mangle() which would
> call NonManglingModuleScope.mangle().  I added an implementation of
> mangle() inside CClassScope to always call outer_scope.mangle(), but
> this ends up breaking code -- I'm not certain why and to figure it out
> would take more time than I'd like to invest at the moment.

Good thinking. Yes, you are correct; if you can file the ticket it would
be great. Looking ahead to solving this there are two ways to go about it:


2) Refactor all the mangling. I'd strongly prefer this as the above (and
all of NonManglingModuleScope) is a bit of a hack. Ideally I think each
scope would call

self.context.mangle(scope, entry)

and then all current mangling rules would be moved to the Context objects.
This seems to be a better design in general (IoC etc.; in particular
Symtab now essentially hard-codes how mangling gets done; having some
strings set in doesn't change that).

Change History (0)

Note: See TracTickets for help on using tickets.