# Bringing more Abstracts Julia
**URL:** https://discourse.julialang.org/t/bringing-more-abstracts-julia/3760
**Category:** Internals & Design
**Tags:** proposal
**Created:** [May 17, 2017, 4:43am UTC](https://discourse.julialang.org/t/bringing-more-abstracts-julia/3760 "2017-05-17T04:43:39Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [May 17, 2017, 4:43am UTC](https://discourse.julialang.org/t/bringing-more-abstracts-julia/3760/1 "2017-05-17T04:43:39Z")
Some Abstract types are used within Julia base (e.g. AbstractTime, AbstractArray, AbstractToken). Others are in use through substantive packages (e.g. AbstractInterval, AbstractTimeSeries, AbstractModel). It seems to me that package ecosystem interworkings would be advanced were Julia to export (maybe from Base.Abstractions) specific Abstract terms for abstractions of wide interest or deep reliance.
---
### Author:  [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)
#### Post date: [May 17, 2017, 5:45am UTC](https://discourse.julialang.org/t/bringing-more-abstracts-julia/3760/2 "2017-05-17T05:45:52Z")
I think more important would be some “standard function names” set as blank which can be imported and extended. That would lessen the need for `*Base` packages.
---
### Author:  [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)
#### Post date: [May 17, 2017, 5:48am UTC](https://discourse.julialang.org/t/bringing-more-abstracts-julia/3760/4 "2017-05-17T05:48:11Z")
Though this has to be carefully done. It seems
```julia
function plot end
```
would make sense because lots of packages seem to use it and step over each other. However, if type-piracy rules were enforced, the APIs would have to be completely changed.
---
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [May 17, 2017, 6:52am UTC](https://discourse.julialang.org/t/bringing-more-abstracts-julia/3760/5 "2017-05-17T06:52:14Z")
Now is the best time to introduce better ways because later is too late.
---
### Author:  [@stephancb](https://discourse.julialang.org/u/stephancb)
#### Post date: [May 17, 2017, 9:54am UTC](https://discourse.julialang.org/t/bringing-more-abstracts-julia/3760/6 "2017-05-17T09:54:14Z")
I have been missing `AbstractComposite`, in order to code functions that work with composite types (having fieldnames), vs e.g. Vectors. But It would require, that _all_ composite types are an AbstractComposite (presently their supertype is `Any`).
My present workaround is
```julia
if length(fieldnames(arg))>0
dosomethingwithfields(arg)
else
dosomethingwithelements(arg)
end
```
---
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [May 18, 2017, 1:40am UTC](https://discourse.julialang.org/t/bringing-more-abstracts-julia/3760/7 "2017-05-18T01:40:32Z")
Consider `abstract type AbstractTimeSeries end`
and also `abstract type AbstractTimeSeries{TimeType} end`
Whichever the community prefer, choosing one and having that be available to all with `import Abstract: AbstractTimeSeries` would do more to let various time series related modules just work or interwork or intrasubstitute. The alternative is to have a package that is very facile with aspect A of time series operations and another package that handles aspect B well – where the use of both together becomes a bridge too far.
---
### Author:  [@cortner](https://discourse.julialang.org/u/cortner)
#### Post date: [May 18, 2017, 2:33pm UTC](https://discourse.julialang.org/t/bringing-more-abstracts-julia/3760/8 "2017-05-18T14:33:56Z")
> I think more important would be some “standard function names” set as blank which can be imported and extended. That would lessen the need for \*Base packages.
Personally, I’d like that as well, but I asked this question somewhere concerning the function name `update!`. I didn’t get the feeling there was any sympathy towards that POV.
---
### Author:  [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)
#### Post date: [May 18, 2017, 2:47pm UTC](https://discourse.julialang.org/t/bringing-more-abstracts-julia/3760/9 "2017-05-18T14:47:28Z")
I think one of the obstacles to doing something like this is that abstract types often imply a specific interface, and currently there is no way to enforce this. Even if there were, doing so on lots of abstract types that aren’t actually used in `Base` would be sacrificing a great deal of flexibility.
I think a better solution would be to allow for some sort of standard way of allowing package developers to declare functions of the same name without producing errors or warnings and without referring to each others packages. For example, `plot` was mentioned, and everyone knows lots of packages export this function. It seems a bit silly to declare it in `Base` just because it’s a common word, but having something like
```julia
@coexist plot(p) = do_stuff(p)
```
would be nice. I don’t actually think this is possible in v0.6, but I may be wrong. I don’t know what compilation issues this would cause, if any. Perhaps one way of doing this would be to have a `CommonFunctions` module that only stores blank function declarations and gets recompiled whenever a packages using one of these functions is included.
---
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [May 18, 2017, 3:43pm UTC](https://discourse.julialang.org/t/bringing-more-abstracts-julia/3760/10 "2017-05-18T15:43:03Z")
Julia’s **protocols** provide us with the technology to specify, convey, enact, and validate specification conformance for apis and other flexibly refocusable capabilities.
🚴♂️🎁🚴♂️ (delivery this Fall, if it happen then)
---
### Author:  [@m-j-w](https://discourse.julialang.org/u/m-j-w)
#### Post date: [May 18, 2017, 5:50pm UTC](https://discourse.julialang.org/t/bringing-more-abstracts-julia/3760/11 "2017-05-18T17:50:55Z")
I don’t think Base would be the right place for something like that. An option for frequently occurring function names might to create a package that just defines all those function names, possibly even with a suggested usage pattern, respectively order, type and purpose of arguments.
Other packages could pull that package as dependency and extend with their own methods.
If that common package is not going into Base, then it can also be updated and evolve independently and possibly faster. Also, this would make it somewhat independent from Julia versions it is used with.
For instance something like
```nohighlight
"""
Module `Commons` provides function prototypes and proposes
canonical usage patterns for commonly defined function names.
Implementations are to be provided by packages that want to
adhere to these patterns.
"""
module Commons
export update!
"""
update!(x, ...)
Common function to update an object. The specific arguments
depend on the package providing the implementation of both
the object `x` and the method it is dispatched to.
"""
function update! end
end # module
```
I can imagine something similar for more generic abstract types, which is probably much more difficult to agree upon. Still, having those as an independent package could also allow a faster evolution, in particular if the type tree needs to be extended, say to insert a branch at some level inbetween.
In both cases some of the more popular packages would need to be willing to make such an effort to make it an accepted community standard.
---
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [May 18, 2017, 6:03pm UTC](https://discourse.julialang.org/t/bringing-more-abstracts-julia/3760/12 "2017-05-18T18:03:28Z")
that is good thinking – (for clarity, I had considered only the Abstract type declarations being available with Julia … I agree that more than that is too much)
as is the case with import Base.Dates:AbstractTime
I do not want to remember where each major Abstract type resides to import it.
If there were a Package, CommonAbstractTypes.jl that exported AbstractTime, AbstractInterval, … without any more specification than the single line declarations, might that fly?