When I've seen people get into this state, it's a disaster. Having two different types that look the same but are actually different and some methods specialized on one and others on the other is very confusing and not helpful at all. If you want to do this intentionally, it's pretty easy to wrap the code you're working on in a module and reload the entire module – type definitions and generic functions that apply to them. That already works and doesn't lead to the crazy amount of confusion that the other situation does.
On Fri, Feb 5, 2016 at 11:13 AM, Scott Jones <[email protected]> wrote: > Types themselves are immutable, right? > Don't instances in Julia contain a pointer to their type? > If a type's definition were replaced, would the old (now obsolete) > instances still point to the old definition? Would they still correctly > use methods specialized on the old definition? > If so, it seems that you could redefine types without much problem, as > long as you didn't expect the > old instance's data to be migrated. > > I think that would be very useful in the REPL. > Often I have lots of data in objects totally unaffected by the type I'm > working on, and it's a pain to have to save data, restart, recompile, > reload data constantly during development. > > On Thursday, February 4, 2016 at 1:46:45 PM UTC-5, Michael Landis wrote: >> >> I think it would be nice to be able to undefine a type, so restarting the >> environment is not required when adding or deleting an attribute from a >> type description. Not being able to update a type definition without >> restarting the environment is a royal pain in the ass. >> >> On Saturday, March 8, 2014 at 9:55:37 AM UTC-8, Freddy Chua wrote: >>> >>> Suppose I have a Type >>> >>> type Foo >>> a >>> b >>> end >>> >>> f = Foo(1,2) >>> f.a = 1 >>> f.b = 2 >>> >>> how do I test whether f.a is defined >>> I do this isdefined(f, 1) but isdefined(f, 'a') does not work >>> >>> another question >>> how do i undefine f.a such that isdefined(f,1) now returns false >>> >>
