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.
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
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?
Hold on. I'll find some links.
This issue is probably the best starting place: <https://github.com/JuliaLang/julia/issues/4935>
Thanks a bunch @Adam non-jedi Beckmeyer ! I sometimes shoot from the hip instead of going into Discourse. Indeed, that's a bad habit.
And maybe this discourse thread? https://discourse.julialang.org/t/composition-and-inheritance-the-julian-way/11231
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:
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.
hahaha, no worries about the pop-corn, it's actually a good heads-up that I was diving in troubling waters.
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/>
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.
Hmm, could you be explicit @jar ? Maybe an example. I'm not visualizing.
do you have a sorta elementary (not too mathy) example in mind?
Geometric objects perhaps.
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
.
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
If I want to expose width/height/length I can define functions for them
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?
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"
julia should have a way to declare all s::Shape
s have an area(s)
, and there are a few packages for doing that but nothing in Base yet
Ah, ok. Thanks a lot for the example and explanation
Last updated: Nov 22 2024 at 04:41 UTC