Re: [PATCH 2/3] allow builtins to have prototype and evaluate/expand methods

[Chris Li <christ.li@gmail.com>]

On Sun, Feb 12, 2017 at 11:03 PM, Luc Van Oostenryck
<luc.vanoostenryck@gmail.com> wrote:
> OK, I've look at this.
> The difference between your patch and mine is that yours share/
> migrate the methods for all symbols while mine purposely did that
> for builtins only. The reasons I did this way was to avoid to share

That to me is actually not the main difference. Yes, the one line patch
is simple and apply op to all symbol has the same name.
If we need, we can make that migrate code into a function and do
some special handing for builtin etc. I just don't see the need for
that right now.

The big difference I see is the solve the problem at symbol creating
side rather than symbol usage side.

In the future, we can make migrate symbol only return symbol are
new (and has incremental difference). Totally drop the symbol which
is the exact same abstract declare as the previous one.

> methods between things that don't need to, for example if someone
> define a function that have the same name as one of the numerous
> attributes (which are not reserved keywords and aren't necessarily
> protected by leading double underscore). But having look at this now,
> I see that it should never be a problem when this happen (but is it
> a good idea?).

Even if that became a problem, we can add some code to deal with
it. E.g. conditionally migrate some symbol information.

Chris