I am a relatively newbie and I am wondering what is the most appropriate Julian way to reuse the code. I don’t want to trigger discussions on topics already discussed a million times. This post simply aims to lay down a clear list of rules to be followed to write good Julia code, and pose a couple…

[image] gcalderone: In this case we are not tied to the Person layout, but we have to re-define all the methods accepting a Person object. This process can be automatized using macros but we still get lots of further entries in the dispatch table. You don’t have to re-define all the methods a…

I think all that can be simplified a bit, if every type that uses Person and wishes to use it’s functions, simply had a person function. Try the following: abstract type AbstractPerson end # basic methods to define: name,age,set_age #basic AbstractPerson mutable struct Person <: AbstractPerson …

[image] ScottPJones: I think all that can be simplified a bit, if every type that uses Person and wishes to use it’s functions, simply had a person function. To be fair though, your example is covered by getproperty overloading. [image] favba: You don’t have to re-define all the methods …

[image] ChrisRackauckas: Now just forward the array interface onto x and you’re good. The key point here is the word just. For a simple example you’re definitely right. But for a real life application (such as wrapping a DataFrame object as we discussd above) this implies redefining ~200 me…

Thanks @ScottPJones !!! You’re solution is definitely a very interesting one, and I think it definitely solve the problem in the first discussion of this post. You’re great!! :+1::+1: In brief, your solution uses composition of structures and avoid useless methods re-definition. Clearly, as note…

[image] gcalderone: The key point here is the word just . For a simple example you’re definitely right. But for a real life application (such as wrapping a DataFrame object as we discussd above) this implies redefining ~200 methods. Of course a few of these (namely all those returning a DataFram…

Now the bad news: despite the very clever suggestion by @ScottPJones this solution can not be applied in general, since it works only if the object you wish to extend/customize already uses the person(a::Person) = a method internally, which doesn’t apply to DataFrame…

It seems that there are two tasks, then for DataFrames, if you were to create a new type for metadata (which you don’t have to do! maintainers seem amenable to metadata living in DataFrames) First, make sure DataFrames methods only take in AbstractDataFrame. Second, categorize which functions absol…

[image] pdeffebach: First, make sure DataFrames methods only take in AbstractDataFrame . Second, categorize which functions absolutely need to be defined toe AbstractDataFrame to work. Maybe there already exists a list somewhere? Or we could work on getting that list together and shortened. A go…

Composition and inheritance: the Julian way

General Usage

foobar_lv2 June 1, 2018, 3:57pm 64

One apparently officially questionable way is discussed in https://discourse.julialang.org/t/getproperty-decorations-inheritance-in-0-7/11237.

Topic		Replies	Views
Workaround for traditional inheritance features in object-oriented languages General Usage inheritance , structtypes	40	10440	November 14, 2017
About inheritance and abstract types New to Julia inheritance	46	10622	June 12, 2020
Add type mixins to overcome subtype limitations Internals & Design	41	7068	May 29, 2017
Method inheritance the Julian way New to Julia inheritance	18	2664	August 29, 2021
Is Julia's way of OOP superior to C++/Python? Why Julia doesn't use class-based OOP? Internals & Design	146	34175	October 11, 2021

Composition and inheritance: the Julian way

Related topics