Vocabulary when using NamedTuples and Structs

General Usage
1

This may seem like an odd post, but bare with me here.

I’m assuming most, if not all of us here had some experience with OO languages, so it’s normal to hear terms like object, has-a, or is-a.

  1. When you use a NamedTuple, is it correct to say that we have an object?
Fruit = @NamedTuple(name::String,Type::String, color::String)
ambrosia::Fruit = (name = "Ambrosia", Type="Apple" color = "Red")

Is it correct to say ambrosia is a object of Fruit?

  1. If we really wanted to go deeper, fruits obviously have certain attributes, name, colour, places of origin, etc…

It’s easy to see the has-a relationship and model a NamedTuple or struct this way, but is it correct to think of it that way?

  1. If we go deeper, we could model our fruits this way AbstractFruit > Apple, in the documentation it uses the word subtype, so Apple would be a subtype of AbstractFruit.

It’s easy to see the is-a relationship, so, is it correct to think of it that way?

I only ask this because, on the surface, it might be easy to explain that a variable name is like a box to store a value, and in languages such as Java and C# that might be true, but that thinking breaks down in languages like Python and Julia.

I’m not asking how to do OOP in Julia, but rather how do we take certain OO concepts and think about them the Julia way.

2

I cannot really reproduce your example there (I could not figure out how to use that @NamedTuple macro and what it solves, by the way, even reading the help).

But if you do:

julia> Fruit = @NamedTuple{name::String, type::String, color::String}
NamedTuple{(:name, :type, :color),Tuple{String,String,String}}

julia> x = (name="a",type="b",color="c")
(name = "a", type = "b", color = "c")

julia> typeof(x)
NamedTuple{(:name, :type, :color),Tuple{String,String,String}}

julia> x isa Fruit
true

Thus, I think we can say that x is a Fruit, yes. But that Fruit is a concrete type, thus it does not have any subtype:

julia> subtypes(Fruit)
Type[]

So it is not exactly as if Fruit was an abstract concept below which things with different sets of properties could exist. It would only make sense that calling the most general type that can characterize any fruit if all different fruit attributes where listed there.

One can explicitly use these concepts with structs:

julia> abstract type Fruit end

julia> struct Apple <: Fruit
         color 
       end

julia> struct Banana <: Fruit
          type
       end

julia> one_apple = Apple("Red")
Apple("Red")

julia> one_apple isa Apple
true

julia> one_apple isa Fruit
true

julia> one_banana = Banana("Nanica")
Banana("Nanica")

julia> one_banana isa Banana
true

julia> one_banana isa Fruit
true

# of course
julia> subtypes(Fruit)
2-element Array{Any,1}:
 Apple
 Banana

I do not see any harm in calling these things “objects”, for lack of words, but that does not completely fit into the object concept in programming, because objects can contain methods, and these “objects”, don’t.

3

Good question!

As you become more familiar with Julia, rather than “take certain OO concepts and think about them the Julian way” you are likely to consider aspects of Julia’s design, approach, and best practices as overlapping conceptual underpinnings of the Object Oriented perspective rather than seeking the deeper philosophical meld. That’s what I found most helpful.

Welcome to The Julia Community.

2 Likes
4

That really depends on how you want to think about it.

For example, one of the OOP definitions is that “objects contain data and code”, and since it is more typical to define methods using multiple dispatch in Julia, which are not really “contained” in a value or a type, most things are not objects.

Or you can take the view that everything is an object. :wink:

Personally, I would sidestep/ignore most OO concepts and as I do not find them helpful for programming Julia.

1 Like