An easier path forward might be to mimic python types with dictionaries and macros (and containers for the dictionaries).
On Fri, Feb 5, 2016 at 7:04 AM, Stefan Karpinski <[email protected]> wrote: > 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 >>>>> >>>>> >> >
