Parametric Field Names

General Usage
1

Consider Following Situation:

I want to model an object with struct in Julia. I want this object fields be mutable. The goal is that when we change one of the fields, the rest of the fields will change automatically.

To define a specific problem, consider a dummy structure Square, The field names are: side_length and area. I want when I Change side_length the area changes automaticly. I know this is not great example for real world use cases

The following Code is definition of this structure:

mutable struct Square
    side
    area
end

s1 = Square(2, 4)

s1.side = 5

println(s1.area) # Obviously the output is 4

I am also curious to know if it is possible for some fields to be made automatically at the time of instantiation? for example at the creation time we only specify the side_length of this structure.

2

Your first question is not easily answered, although I think there are ways to achieve this.

The second question is simple, just define a constructor:

julia> mutable struct Square
           side
           area
       end

julia> Square(side) = Square(side, side^2)
Square

julia> Square(5)
Square(5, 25)
2 Likes
3

https://docs.julialang.org/en/v1/manual/constructors/#man-inner-constructor-methods

The inner constructor is what you use for this kind of things:

It is good practice to provide as few inner constructor methods as possible: only those taking all arguments explicitly and enforcing essential error checking and transformation.

your example falls under ā€œenforcing essential transformationā€

julia> mutable struct Square
           side
           area
       Square(s) = new(s, s^2)
       end

julia> Square(3)
Square(3, 9)

In this case, we can even deliberately disallow the 2-argument constructor because the info is redundent. (assuming itā€™s useful for Square to carry an .area field

3 Likes
4

I donā€™t think you will be able to override Base.setproperty! with this kind of behavior. I just tried it and ended up in a nest of StackOverflow errors.

Best to do a changesidelength!(x) method which does both steps.

1 Like
5

You could perhaps accomplish your first goal by making use of either set methods or making the struct fields Observable using Observables.jl and attach the recalculation behavior to the observable callback.

1 Like
6

What if you implement setproperty using setfield rather than recursively calling setproperty?

2 Likes
7

Seems like setproperty! is the way to go (using setfield! internally to avoid the stack-overflow).

E.g.

mutable struct Square
   side
   area
end
function Base.setproperty!(x::Square, field::Symbol, val)
  if field == :side
    setfield!(x, :side, val)
    setfield!(x, :area, val^2)
  else
    # .. or whatever else you want to do here
    error("oops!")
  end
end

s1 = Square(2,4)
s1.side = 5
println(s1.area)
# output is 25

Alternatively, you could define a set of ā€œderrivedā€ properties that have no fields in the struct, and override propertynames and getproperty and use those to generate the derived properties.

5 Likes
8

Why should it be inner constructor?

julia> mutable struct Square
           side
           area
       end

julia> Square(side) = Square(side, side^2)
julia> Square(3)
Square(3, 9)
9

in your code here, try Square(3, 10). Now you have an illegal instance

3 Likes
10

Ah, you mean if someone want to lock users out from instantiating some fields directly? Yes, it makes sense than.

One should override area field also, so it can be accessed read only.

11

How would you implement a setside!(s::Sqaure, len) if you do this? also you canā€™t make something truly read-only anyways, just donā€™t bother. If someone insists, they can break Julia itself easily.

12

Yes, you are right again. But in this case inner constructor is not providing real protection, so itā€™s ok to use outer constructor.

s = Square(3)
s.area = 10

Just two lines instead of one. Hardly worth inner constructor (especially taking into account that in order to change it one needs to restart REPL).

13

User should know not to do this. In some class-based OOP, this is ā€œprotectedā€ by making s.area a ā€œprivateā€ variable and s.get_area() to be ā€œread-onlyā€. But in the end of the day it only increase development overhead. You have to trust user not to deliberately digging holes for themselves at some point anyway.

1 Like
14

DataFrames has checks for corrupted DataFrames. Before operations, it makes sure all vectors are the right size. OP could also implement this.

But really, @dariush-bahrami , just store the side-length and use helper functions to do all that stuff for you.

15

Personally Iā€™am not a huge friend of storing redundant data, and you can avoid any illegal instance by just storing the essential information once. Found this originally here and meanwhile using this quite extensively:

mutable struct Square
    side
end

# Acutally not strictly needed just for completeness
# see https://docs.julialang.org/en/v1/base/base/#Base.propertynames   
propertynames(p::Square,private=true) = begin
    fields = fieldnames(typeof(p))    
    (fields...,:area,:diagonal)
end

#Dispatch the gets
Base.getproperty(p::Square,n::Symbol) = getproperty(p::Square,Val{n}())
Base.getproperty(p::Square,::Val{S}) where {S} = getfield(p,S)  #generic fallback
Base.getproperty(p::Square,::Val{:area}) = p.side^2
Base.getproperty(p::Square,::Val{:diagonal}) = āˆš2*p.side

#Dispatch the sets
Base.setproperty!(p::Square,n::Symbol,x) = setproperty!(p,Val{n}(),x)
Base.setproperty!(p::Square,::Val{S},x) where {S} = setfield!(p,S,x)     #generic fallback
Base.setproperty!(p::Square, ::Val{:area},x) = setfield!(p,:side,āˆšx)
Base.setproperty!(p::Square, ::Val{:diagonal},x) = setfield!(p,:side,x/āˆš2)



julia> s = Square(āˆš2)
Square(1.4142135623730951)

julia> s = Square(āˆš2)^C

julia> s.diagonal
2.0000000000000004

julia> s.area=4
4

julia> s.diagonal
2.8284271247461903

julia>

It is also easier to maintain this way and you can easily add up more implicit properties without stressing your memory too much.

2 Likes
16

I agree that can make a lot of sense. That was the reason for the ā€œAlternatively, you could define a set of ā€œderrivedā€ properties that have no fields in the struct, and override propertynames and getproperty and use those to generate the derived properties.ā€ part of my comment.

I think which route you goā€”the setproperty! or the getproperty routeā€”depends a lot on the exact tradeoffs of the problem. That is, do you care more about memory or compute complexity for the actual problem you want to solve.

1 Like
17

Thank you very much. This solution seems to be the most straightforward.