# @eval vs defining on module

**URL:** <https://discourse.julialang.org/t/eval-vs-defining-on-module/60083>\
**Category:** General Usage\
**Tags:** question\
**Created:** [April 27, 2021, 5:26am UTC](https://discourse.julialang.org/t/eval-vs-defining-on-module/60083 "2021-04-27T05:26:33Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![jzr](https://avatars.discourse-cdn.com/v4/letter/j/eb9ed0/32.png) [@jzr](https://discourse.julialang.org/u/jzr)\
**Post date:** [April 27, 2021, 5:26am UTC](https://discourse.julialang.org/t/eval-vs-defining-on-module/60083/1 "2021-04-27T05:26:34Z")

</div>

In [this question](https://discourse.julialang.org/t/julia-1-6-stacktrace/57981/), users want to change the behavior of a function in `Base`.

What’s the difference between [this post](https://discourse.julialang.org/t/julia-1-6-stacktrace/57981/14)’s suggestion of

```julia
@eval Base begin

path_color = :red

function print_stackframe(io, i, frame::StackFrame, n::Int, digit_align_width, modulecolor)
...

```

vs another implementation

```julia
Base.path_color = :red
function Base.print_stackframe(io, i, frame::StackFrame, n::Int, digit_align_width, modulecolor)
...

```

or are they the same? Also what is the proper way to describe these implementations?

---

<div class="post-metadata">

**Author:** ![kristoffer.carlsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kristoffer.carlsson/32/22_2.png) [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)\
**Post date:** [April 27, 2021, 7:53am UTC](https://discourse.julialang.org/t/eval-vs-defining-on-module/60083/2 "2021-04-27T07:53:31Z")

</div>

> [@jzr](#):
>
> What’s the difference between…

```julia
julia> StackFrame
ERROR: UndefVarError: StackFrame not defined

julia> @eval Base begin
           StackFrame
       end
Base.StackTraces.StackFrame

```

So if you don’t eval the code into Base you need to import all the functions/types etc from Base that you want to use.

> [@jzr](#):
>
> Also what is the proper way to describe these implementations?

I would call it “method overwriting”.