Stream: helpdesk (published)

Topic: Why Julia does not allow Concrete SubTypes?


view this post on Zulip Davi Sales Barreira (Feb 06 2022 at 20:52):

This is related to the question I just posted below on Julia's programming paradigm. One thing that sometimes I find unintuitive in Julia is the fact that I cannot create "subtypes" of my concrete types. I mean, suppose I create a struct Topological Space. Now, such struct has some fields. Then, I decide I want to create a new struct, a Topological Metric Space. Now, my new struct is also a topological space, so it should share all the fields in Topological Space and theoretically, it should be a subtype of Topological Space. But this is not allowed in Julia. I was wondering what would be the reason for this, and if there is a "Julia-way" of thinking of these kind of structs.

view this post on Zulip Davi Sales Barreira (Feb 06 2022 at 20:53):

Oh boy, the popcorn emoji is making me afraid :fear: I'm sorry if this question is ill posed and if I'm actually quite wrong in my assumptions

view this post on Zulip Adam non-jedi Beckmeyer (Feb 06 2022 at 20:54):

There's been several dozens of threads on this on the Julia discourse and several issues on the julialang github on the topic as well. I think linking to those discussions is going to be more helpful than giving an overview here, and maybe then answering more specific questions?

view this post on Zulip Adam non-jedi Beckmeyer (Feb 06 2022 at 20:54):

Hold on. I'll find some links.

view this post on Zulip Adam non-jedi Beckmeyer (Feb 06 2022 at 20:55):

This issue is probably the best starting place: <https://github.com/JuliaLang/julia/issues/4935>

view this post on Zulip Davi Sales Barreira (Feb 06 2022 at 20:55):

Thanks a bunch @Adam non-jedi Beckmeyer ! I sometimes shoot from the hip instead of going into Discourse. Indeed, that's a bad habit.

view this post on Zulip Adam non-jedi Beckmeyer (Feb 06 2022 at 20:55):

And maybe this discourse thread? https://discourse.julialang.org/t/composition-and-inheritance-the-julian-way/11231

view this post on Zulip Adam non-jedi Beckmeyer (Feb 06 2022 at 20:56):

No problem. Sorry if the popcorn emoji came across as snarky. There's just a very typical course this discussion often takes which is very :popcorn:

view this post on Zulip Adam non-jedi Beckmeyer (Feb 06 2022 at 20:56):

Don't think there's anything wrong with asking questions without having done 6 hours of research beforehand. You just happened to hit on a hot-button topic.

view this post on Zulip Davi Sales Barreira (Feb 06 2022 at 20:57):

hahaha, no worries about the pop-corn, it's actually a good heads-up that I was diving in troubling waters.

view this post on Zulip Adam non-jedi Beckmeyer (Feb 06 2022 at 20:58):

This blog post is probably also apropos and doesn't require wading through a bunch of mostly irrelevant comments: <http://www.stochasticlifestyle.com/type-dispatch-design-post-object-oriented-programming-julia/>

view this post on Zulip jar (Feb 06 2022 at 21:02):

I tend to think fields are an implementation detail and making them part of the public interface is bad. Functions are very extensible; fields are not, so they shouldn't be public. And even if fields were extensible, that would just be another way of projecting from an object, when we already have a perfectly good one. If I want to provide a common API for two types, I define a generic function that can be implemented for both.

view this post on Zulip Davi Sales Barreira (Feb 06 2022 at 21:04):

Hmm, could you be explicit @jar ? Maybe an example. I'm not visualizing.

view this post on Zulip jar (Feb 06 2022 at 21:09):

do you have a sorta elementary (not too mathy) example in mind?

view this post on Zulip Davi Sales Barreira (Feb 06 2022 at 21:09):

Geometric objects perhaps.

view this post on Zulip Davi Sales Barreira (Feb 06 2022 at 21:10):

I saw in the link posted by @Adam non-jedi Beckmeyer a nice "solution", where the author created a hierarchy of abstract types, and then created a concrete type in the "leaves". Like, he created both abstract rectangle and concrete reactangle.

view this post on Zulip jar (Feb 06 2022 at 21:15):

If I make

abstract type Shape end
function area end

struct Rectangle <: Shape
  width
  height
end
area(r::Rectangle) = r.width * r.height

struct Square <: Shape
  length
end
area(s::Square) = s.length ^ 2

area is a public function; .width .height .length are private

view this post on Zulip jar (Feb 06 2022 at 21:16):

If I want to expose width/height/length I can define functions for them

view this post on Zulip Davi Sales Barreira (Feb 06 2022 at 21:17):

So, layman's question. Why do you say they are private? I mean, if I "use" your package, wouldn't I have access to them?

view this post on Zulip jar (Feb 06 2022 at 21:19):

it's a bit metaphysical since julia won't enforce privacy but the idea is there's a social contract where the library author provides some things publicly and says "this is the public interface of my package, anything else is internal and may change or break without notice"

view this post on Zulip jar (Feb 06 2022 at 21:23):

julia should have a way to declare all s::Shapes have an area(s), and there are a few packages for doing that but nothing in Base yet

view this post on Zulip Davi Sales Barreira (Feb 06 2022 at 21:31):

Ah, ok. Thanks a lot for the example and explanation


Last updated: Nov 22 2024 at 04:41 UTC