Yes, I think you've got the right idea. Really there's Qux, QuxOld, QuxOldOld, QuxOldOldOld, etc., but it's not showing you those Old parts of the name.
Regarding variables of old types: yep, that's frequently a source of confusion. The example at the end of the FAQ section shows an example: http://docs.julialang.org/en/latest/manual/faq/#how-can-i-modify-the-declaration-of-a-type-immutable-in-my-session --Tim On Wednesday, July 16, 2014 07:46:14 AM Tomas Lycken wrote: > I think I managed to gain some futher understanding here, but I'm really > uncertain if this is correct, so I'd really appreciate if someone who > actually understands what's going on would confirm or correct this: > > What I *think* happens, is that each time the file is included, a *new* > type with the same (fully qualified) name is defined, and a method is added > to the function for the new type. For most functions, since the function is > also replaced, this doesn't really constitute a problem, but since this > code is extending a function from somewhere else, the function isn't > replaced, and so methods are just added on top of each other. The main > reason it's so confusing is that all the types have the same fully > qualified names, so there is really no way for me as a user to know which > one of them is the latest version. I think I've seen an issue about this on > the tracker, but now I can't find it. > > Does this seem like a possible explanation of the behavior above? My > original problem could then be that I was keeping old variables, of old > versions of the type, around - does that also seem reasonable? > > Thanks, > > // Tomas > > On Wednesday, July 16, 2014 1:15:23 PM UTC+2, Tomas Lycken wrote: > > If a I import a function explicitly into a module and extend it with new > > methods, Julia seems to become quite confused when I replace the module, > > adding more methods with exactly the same signatures as the ones already > > there. > > > > I have a complete gist outlining the problem > > <https://gist.github.com/tlycken/ea7781b2eaedccfef12a> (just put all > > three files in the same folder and execute julia demo.jl) but in summary, > > the oddness is shown if you call methods on the extended function after a > > few inclusions: > > > > julia> methods(Foo.bar) > > # 8 methods for generic function "bar": > > bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 > > bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 > > bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 > > bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 > > bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 > > bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 > > bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 > > bar(x) at /home/tlycken/coding/Julia/Foo.jl:6 > > > > It still seems to work in this case - bar(Qux(3)) does what it should - > > but I’m having trouble in my real application (where I’m extending layer > > from Gadfly.jl) because I’m getting MethodErrors for signatures that > > methods say are there. > > > > Is this a known problem? I couldn’t find anything in the issue list on > > Github, but I admit that I found it quite difficult to figure out what to > > search for… > > > > // T > >
