I'm a little confused about what you feel is missing. You can do duck typing just as well as in any dynamic language. While it's true that there aren't explicit interfaces (or protocols or concepts), those don't exist in Python either. Julia's abstract types give you everything that interfaces/protocols/concepts do except for (a) multiple inheritance and (b) the ability to explicitly require the implementation of certain methods.
A couple of examples of informal protocols that are used all the time in Julia and allow user defined types to easily hook into predefined generic behaviors are the start/done/next protocol for iteration and the order and sort! protocols ordering and sorting things. The ModInt example<https://github.com/JuliaLang/julia/blob/master/examples/modint.jl>shows that if you just define addition and multiplication for a new user-defined numeric type, you can immediately construct matrices of that type and multiply them (unfortunately, this example is currently broken<https://github.com/JuliaLang/julia/issues/6461> ). I can't think of any languages where user defined types are as first class as they are in Julia. As Jameson noted, there is almost no distinction – most "built in" types are really just user defined types that are defined for you. Even basic types like integers are defined in Julia<https://github.com/JuliaLang/julia/blob/cf32395b30d235368bfd52e2896051c9be827ff0/base/boot.jl#L170-L199> and given all of their behaviors<https://github.com/JuliaLang/julia/blob/master/base/int.jl>in Julia. Even in Scheme, integers and their behavior are built in. Is it the lack of multiple inheritance that's throwing you? Lack of formal specifications for protocols? The fact that generic functions live outside of types? On Mon, Apr 7, 2014 at 10:43 PM, Jameson Nash <[email protected]> wrote: > 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 <[email protected]> > 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. > >> > > >
