Simplify init

[mcocdawc]

• moved the saving operation out of the init method.

• don't redundantly store information from fobj, but use fobj itself directly.

[mscho527]

I'll have to think a little bit more, but I am a bit wary of directly using self.fobj. If we are concerned about the redundant information we are retaining here, is there a reason why we wouldn't take the information from the fobj in the init and not retain self.fobj instead? I'll think about this a bit longer and update lol; just my very first thoughts :)

[mcocdawc]

I'll have to think a little bit more, but I am a bit wary of directly using self.fobj. If we are concerned about the redundant information we are retaining here, is there a reason why we wouldn't take the information from the fobj in the init and not retain self.fobj instead? I'll think about this a bit longer and update lol; just my very first thoughts :)

The reason why the fragpart (it's the type of self.fobj) class exists, is that its components Nfrag or fsites belong together and it makes sense to collect them into a class. If we were using only one or two components of self.fobj, then I could live with extracting them from self.fobj, but the way it is written currently we extract all components of self.fobj and unnecessarily break encapsulation.

This is:

1. Unnecessarily verbose
2. Hard to maintain.
   2.1. What do you do if you add a component to fragpart? Do you always have to remember to add it also to BE?¹
   2.2. What do you do if you change the representation of fragments altogether? At the moment you have to change unnecessarily much in BE.
3. Redundant. Do you use self.fobj.Nfrag or self.Nfrag? If we have self.Nfrag, then we should not also store self.fobj, or the other way round.

¹ That's not hypothetical. I need to store some more lookup information per fragment for the faster integral transformation.

---

Just to give a small example where I think it becomes obvious:

Let's say you had a 2D Rectangle:

class Rectangle:
    def __init__(self, a: float, b: float) -> None:
        self.a = a
        self.b = b

    def area(self) -> float:
        return self.a * self.b        

then you can easily implement a Prism on top

class Prism:
    def __init__(self, base: Rectangle, h: float) -> None:
        self.base = base
        self.h = h

    def volume(self) -> float:
        return self.base.area() * self.h

It is easy to see how this code works even with general 2D shapes without any changes (apart from the type hinting)

But you can also unnecessarily couple the Prism to the rectangle:

class CoupledPrism:
    def __init__(self, rectangle: Rectangle, h: float) -> None:
        self.base = rectangle
        self.a = rectangle.a
        self.b = rectangle.b
        self.h = h

    def volume(self) -> float:
        return self.a * self.b * self.h

now you cannot just pass in another 2D shape with an area function, and the code looks more complicated.

Last but not least, writing the uncoupled version is super easy with attrs.define, while the coupled version is a bit more complicated. IMHO it is reliable rule of thumb, that if it is hard to write with attrs.define, then it is probably worse class design.

attrs example

from attrs import define, field

@define
class AttrsPrism:
    base: Rectangle
    h: float

    def volume(self) -> float:
        return self.base.area() * self.h

@define
class CoupledAttrsPrism:
    base: Rectangle
    h: float
    a: float = field(init=False)
    b: float = field(init=False)

     def __attrs_post_init__(self):
        self.a = self.base.a
        self.b = self.base.b

    def volume(self) -> float:
        return self.a * self.b * self.h

[mscho527]

cool cool nice