Even assuming feasibility, implementing this in Julia is a total nightmare – you'd have to recompile huge amounts of code and reconstruct lots of objects – and anything that refers to them, etc. It's almost easier to serialize the entire workspace and reload all code. Basically, the amount of work required makes #265 <https://github.com/JuliaLang/julia/issues/265> look like child's play. Bottom line, I don't think it's going to happen unless someone who feels strongly about it makes a solid pull request to implement it. And there seems to be a negative correlation between the ability to implement this and thinking that it's a good idea to do so.
On Fri, Feb 5, 2016 at 9:55 AM, Stefan Karpinski <[email protected]> wrote: > Python has less of a problem here since it represents object data using a > dict internally – when you reload a class, the representation of objects > doesn't change. Still, if adding or removing fields in Python classes works > at all, that's an interesting data point. > > On Fri, Feb 5, 2016 at 5:24 AM, Andras Niedermayer < > [email protected]> wrote: > >> class X(object): >> @property >> def y(self): >> try: return x.__y >> except AttributeError: return "default value for y" >> >> x = X() >> print x.y >> >> >> >> >> >> On Friday, February 5, 2016 at 11:22:17 AM UTC+1, Andras Niedermayer >> wrote: >>> >>> The IPython autoreload extension does something quite similar to what >>> has been discussed here ( >>> https://ipython.org/ipython-doc/3/config/extensions/autoreload.html ). >>> There are cases where it's actually very convenient, e.g. if you have >>> results from a long-running calculation in an IPython notebook interactive >>> session and you notice that you should change one of the classes, but don't >>> want to rerun the whole calculation. >>> >>> Some of this one gets almost for free in Julia with the Autoreload.jl >>> package, since methods are outside of types in Julia, so there's no need to >>> search for all object of a modified type in memory and add/modify the >>> methods like in Python. (Modifying inlined methods is a bit of a problem, >>> but one could probably extend Autoreload.jl to inject @noinline into >>> modules.) >>> >>> Adding fields would only be possible in Julia if it were possible to >>> overload field access ( https://github.com/JuliaLang/julia/issues/1974 >>> ). >>> >>> That's essentially the way one does this in Python. You add a property >>> getter y to class X, which allows you to access x.y: >>> >>> class X(object): >>> >>> >>> >>> >>> On Friday, February 5, 2016 at 8:17:47 AM UTC+1, Tomas Lycken wrote: >>>> >>>> My main concern is predictability. >>>> >>>> Imagine that I define a type Foo and start playing around with it - >>>> define some functions that work on foot, perhaps one or two types that hold >>>> foos, and manipulate a bunch of Foo instances. >>>> >>>> Then, I redefine the Foo type - say, I add a field. Which of the other >>>> things that I have defined are still valid? >>>> >>>> If I understand the motivation for this feature correctly, it's to make >>>> exploratory programming easier. However, I think it would actually make it >>>> a lot more difficult - it would basically give you a bazooka so heavy that >>>> the only thing you can reasonably aim at is your own foot... >>>> >>>> //T >>>> >>>> >
