# Trait definitions: type level vs instance level

**URL:** https://discourse.julialang.org/t/trait-definitions-type-level-vs-instance-level/103587
**Category:** General Usage
**Created:** [September 6, 2023, 9:16pm UTC](https://discourse.julialang.org/t/trait-definitions-type-level-vs-instance-level/103587 "2023-09-06T21:16:03Z")
**Posts on this page:** 1
**Showing post:** 4

<div class="post-metadata">

### Author: ![Raf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/raf/32/3383_2.png) [@Raf](https://discourse.julialang.org/u/Raf)
#### Post date: [September 7, 2023, 1:30pm UTC](https://discourse.julialang.org/t/trait-definitions-type-level-vs-instance-level/103587/4 "2023-09-07T13:30:29Z")

</div>

Its not a matter of taste, there are clear reasons to define traits on types or on objects.

_Traits on types_  
We often want traits to work inside generated function (where we only have types), or on the eltype of an empty vector. Our target object we want to know the trait of is rarely a singleton - its the trait itself that is a singleton. So `T.instance` is not useful (its also touching internals). So we need to have a trait on the type.

_Traits on objects_  
We cant define the trait on the type if we only know the trait at run time. So the type is useless. For example, we need this in GeoInterface.jl because some objects, like vector points or gdal objects pased in from C, can be 2d or 3d depending on runtime size, So `is3d` has to work on objects rather than types. Nearly always its a compile-time operation (e.g. for a Tuple or GeometryBasics.jl geometry), but having it work on the object means the interface still works when its not, its just slower.

---

_[View the full topic](https://discourse.julialang.org/t/trait-definitions-type-level-vs-instance-level/103587)._