In Julia there is (almost) no distinction between user-defined functions and library code. In fact, an increasing percentage of the "library" code is just pre-packaged Julia functions that happen to live in the Base module ('increasing', because stuff often moves from C to Julia because doing so doesn't sacrifice speed but does it more flexible, such as Stefan's recent work with fast hashing). All code is equally able to provide an implementation of the Base.setindex! function
Note that if you define a new function Main.setindex! without first importing Base.setindex!, you will create a new function. Similar name, but completely separate similarly, backend output swapping is implemented using MIME types in the Base.display function users can either derive from an abstract class you provide (explicit inheritance), or you can define your function to take an object of type Any (duck typing) On Mon, Apr 7, 2014 at 10:28 PM, Mason McGill <mason.b.mcg...@gmail.com> wrote: > The issue is that user-defined functions (in this case, `setindex!`) aren't > accessible from library code. in Python, you can have something like this: > > # module A > def zero(x): > x[:] = 0 > > # module B > class C: > def __setitem__(self, key, value): > print("Perform custom behavior here") > > from A import zero > zero(C()) > > But it doesn't look like there's an idiomatic way to do that in Julia, > meaning you couldn't really implement something like the C++ STL or D > ranges. Some less trivial examples of where this kind of polymorphism is > important: > - I have 10 classes of pedestrian detectors to test. They all have the same > "interface" but are implemented differently. I want to use the test > function my coworker wrote, without having to modify it. > - I'm building a graphical application and I want to be able to swap the > back-ends (e.g. Qt and HTML) with a single function call. > - I'm writing an image processing library and I'd like users to be able to > work with their own data types (like stereo image or spatial pyramid), so > long as those types support fundamental operations (like indexing). > > I hope this clears things up! > > On Monday, April 7, 2014 5:38:03 PM UTC-7, Keno Fischer wrote: >> >> I am unsure as to what your question is. I would probably write the above >> as: >> >> zero!{T}(x::AbstractArray{T}) = fill!(x,zero(T)) >> >> but the way you wrote it works just fine assuming `setindex!` is defined >> correctly. >> >