# Defining my own \`next!\` but avoiding confict

**URL:** https://discourse.julialang.org/t/defining-my-own-next-but-avoiding-confict/95035
**Category:** General Usage
**Created:** [February 22, 2023, 5:55pm UTC](https://discourse.julialang.org/t/defining-my-own-next-but-avoiding-confict/95035 "2023-02-22T17:55:49Z")
**Posts on this page:** 1
**Showing post:** 7

<div class="post-metadata">

### Author: ![CameronBieganek](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cameronbieganek/32/6915_2.png) [@CameronBieganek](https://discourse.julialang.org/u/CameronBieganek)
#### Post date: [February 22, 2023, 7:51pm UTC](https://discourse.julialang.org/t/defining-my-own-next-but-avoiding-confict/95035/7 "2023-02-22T19:51:10Z")

</div>

> [@scheinerman](#):
>
> I was just curious about why this was even necessary since the two `next!` functions take different types of arguments.

There is a very long thread on Discourse about this very subject, but I don’t have a link handy. Basically, the philosophy is that a generic function should have a generic definition that applies to all its methods. In this case, `ProgressMeter.next!` and your `next!` have very different meanings, so they should not be methods of the same generic function.

EDIT: Found the link:

> [@Function name conflict: ADL / function merging?](https://discourse.julialang.org/t/function-name-conflict-adl-function-merging/10335):
>
> Is there any reason why Julia needs me to fully qualify the function name when the argument types are clear and there shouldn’t be any problem with multiple dispatch? Case 1: load JuliaDB before defining Foo julia\> using JuliaDB julia\> stack( stack(t::D) where D\<:Union{IndexedTables.NDSparse, IndexedTables.NextTable} in IndexedTables at /Users/tomkwong/.julia/v0.6/IndexedTables/src/reshape.jl:32 stack(t::D, by; select, variable, value) where D\<:Union{IndexedTables.NDSparse, IndexedTables.Next…

---

_[View the full topic](https://discourse.julialang.org/t/defining-my-own-next-but-avoiding-confict/95035)._