# Should macros observe mutable global state, e.g. method tables?

**URL:** <https://discourse.julialang.org/t/should-macros-observe-mutable-global-state-e-g-method-tables/7405>\
**Category:** General Usage\
**Tags:** question, metaprogramming\
**Created:** [November 30, 2017, 7:18am UTC](https://discourse.julialang.org/t/should-macros-observe-mutable-global-state-e-g-method-tables/7405 "2017-11-30T07:18:09Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![helgee](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/helgee/32/2022_2.png) [@helgee](https://discourse.julialang.org/u/helgee)\
**Post date:** [November 30, 2017, 7:18am UTC](https://discourse.julialang.org/t/should-macros-observe-mutable-global-state-e-g-method-tables/7405/1 "2017-11-30T07:18:09Z")

</div>

My package [Convertible.jl](https://github.com/helgee/Convertible.jl) currently uses generated functions to enable multi-step type conversions at runtime. The problem is that I achieved this by calling `methods` within the generated function body, i.e. I am observing mutable global state which is [considered harmful](https://docs.julialang.org/en/stable/manual/metaprogramming/#Generated-functions-1).

I am now in the process of rewriting the package and want to shift the generation of the missing intermediate `convert` methods to compile-time by using a macro. The question is now whether this actually solves the problem? Can macros safely observe method tables?

---

<div class="post-metadata">

**Author:** ![helgee](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/helgee/32/2022_2.png) [@helgee](https://discourse.julialang.org/u/helgee)\
**Post date:** [December 1, 2017, 2:09pm UTC](https://discourse.julialang.org/t/should-macros-observe-mutable-global-state-e-g-method-tables/7405/2 "2017-12-01T14:09:07Z")

</div>

Anybody? ☹

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [December 1, 2017, 2:24pm UTC](https://discourse.julialang.org/t/should-macros-observe-mutable-global-state-e-g-method-tables/7405/3 "2017-12-01T14:24:22Z")

</div>

I don’t know enough about he internals or your code to say how exactly it would fail, but since macros should just perform syntax transformations, you are probably better off just rewriting the code a different way.

Perhaps if you gave a bit of context, or an MWE that would illustrate the problem you are trying to solve, you could get an alternative solution.

---

<div class="post-metadata">

**Author:** ![cstjean](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cstjean/32/1444_2.png) [@cstjean](https://discourse.julialang.org/u/cstjean)\
**Post date:** [December 1, 2017, 3:43pm UTC](https://discourse.julialang.org/t/should-macros-observe-mutable-global-state-e-g-method-tables/7405/4 "2017-12-01T15:43:15Z")

</div>

> [@helgee](#):
>
> Can macros safely observe method tables?

Maybe, but it breaks my expectations as a user, and it will also break Revise.jl

Couldn’t you do essentially the same with an explicit declaration of convertible types?

```julia
@convertible A -> B -> D -> C -> A

```

or, if you want to avoid the redundancy, read the relationships from the convert statements.

```julia
@convertible begin
Base.convert(::Type{B}, a::A) = B(a.val+1)
Base.convert(::Type{D}, a::A) = D(a.val+1)
Base.convert(::Type{C}, b::B) = C(b.val+1)
Base.convert(::Type{A}, c::C) = A(c.val-2)
end

```

In both cases, you can get rid of the `@convert` macro.

---

<div class="post-metadata">

**Author:** ![helgee](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/helgee/32/2022_2.png) [@helgee](https://discourse.julialang.org/u/helgee)\
**Post date:** [December 1, 2017, 5:34pm UTC](https://discourse.julialang.org/t/should-macros-observe-mutable-global-state-e-g-method-tables/7405/5 "2017-12-01T17:34:23Z")

</div>

What makes it complicated is that I want the user to be able to add new types to the graph at runtime. Maybe the whole thing is premature optimization. I must confess I have not checked whether looking up the intermediate conversion dynamically would actually perform much worse.