On Tuesday, April 8, 2014 2:18:18 PM UTC-7, Stefan Karpinski wrote:
>
> It may not address the cross-module aspect well. We didn't have modules
> when I write it originally, so any documentation of that interaction would
> necessarily be tacked on.
>
> "Modules" comes after "Methods", so "Modul
It may not address the cross-module aspect well. We didn't have modules
when I write it originally, so any documentation of that interaction would
necessarily be tacked on.
On Tue, Apr 8, 2014 at 5:16 PM, John Travers wrote:
> On Tuesday, April 8, 2014 10:44:47 PM UTC+2, Mason McGill wrote:
>>
On Tuesday, April 8, 2014 10:44:47 PM UTC+2, Mason McGill wrote:
>
> At the moment, though, it doesn't look like the difference between
> declaring new functions extending existing functions is in the relevant
> sections of the language documentation (I searched "Methods", "Functions",
> "Types"
On Tuesday, April 8, 2014 1:23:57 PM UTC-7, Stefan Karpinski wrote:
>
> On Tue, Apr 8, 2014 at 4:10 PM, Mason McGill
>
> > wrote:
>
>>
>> After all this is sorted out, I'd be happy to distill this into a
>> subsection for the Julia "Types" documentation about conventions for
>> programming wi
No problem – glad we could clear up the confusion. Generic functions take a
little getting used to, but once you do, they're extremely powerful and
quite intuitive.
On Tue, Apr 8, 2014 at 4:30 PM, Mason McGill wrote:
>
>
> On Tuesday, April 8, 2014 1:17:06 PM UTC-7, Isaiah wrote:
>>
>> This is
On Tuesday, April 8, 2014 1:17:06 PM UTC-7, Isaiah wrote:
>
> This is what I was looking for; so if I understand you correctly, you
>> satisfy protocols by extending/monkey-patching Base. This seems
>> reasonable, but what do you do when you want to define your own protocol
>> (e.g. Classifie
On Tue, Apr 8, 2014 at 4:10 PM, Mason McGill wrote:
>
> This is what I was looking for; so if I understand you correctly, you
> satisfy protocols by extending/monkey-patching Base.
>
An important distinction between this and monkey-patching is that if you
create a new type and then only define me
>
> This is what I was looking for; so if I understand you correctly, you
> satisfy protocols by extending/monkey-patching Base. This seems
> reasonable, but what do you do when you want to define your own protocol
> (e.g. Classifier), and Base doesn't have the functions you'd like to
> require (e
On Monday, April 7, 2014 8:51:20 PM UTC-7, Stefan Karpinski wrote:
>
> 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
... and the ModInt example is fixed again:
julia> include("examples/modint.jl")
showcompact (generic function with 8 methods)
julia> A = map(ModInt{11}, rand(1:1000,5,5))
5x5 Array{ModInt{11},2}:
10 1 6 5 1
10 9 6 10 8
2 9 2 1 6
10 4 3 2 8
6 5 2 3 10
julia> B =
Short answer: if a user adds a method to `Base.setindex!`, it *will*
be accessible to library code.
The difference from python here is that python has a single namespace
of method names: if your object has a method `__setitem__`, *all*
python code that says `x[...]=...` might call it. In julia, yo
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/prot
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 do
gmail got confused and remove Mason's actual question, to which I was
responding:
I'd like to write a library that includes functions that can operate
on user-defined types and delegate part of their implementation to
user-defined functions. For example:
zero!(x) = (x[1:end] = 0)
where `x` co
Generally, you would define an abstract type that the user would
inherit. Inheriting from an abstract type is essentially a declaration
that the child class will provide definitions for some
functions/behavior
You would also define prototypes for any functions the user code is
expected to implemen
15 matches
Mail list logo