mfs: add Inode interface

[schomatis]

As suggested in #5094 (comment).

---

mfs: add `Inode` interface

Abstract common characteristics of the MFS `File` and `Directory` structures
inside a separate interface called `Ìnode`.

---

Closes #5094.

[magik6k]

Why not access these directly? Would be cleaner imo (and look less than java)

[schomatis]

Why not access these directly?

To make it explicit that it is a read-only attribute and should not be modified.

(and look less than java)

Would you prefer just using Name()?

https://golang.org/doc/effective_go.html#Getters

[schomatis]

To make it explicit that it is a read-only attribute and should not be modified.

This is actually not happening right now in this PR, parent is being directly accessed and I didn't even noticed it. I need to rethink this, adding Inode as a named field to protect its members would look ugly: d.inode.parent().closeChild().

https://stackoverflow.com/a/32535022

[schomatis]

As mentioned in the Stack Overflow answer, the customary Go solution seems to be to define an interface (Inode) and a separate structure to implement it.

[schomatis]

Is this the appropriate name for the structure that implements the Inode interface?

[whyrusleeping]

Yeah, thats what I would do.

[Stebalien]

Given that this is just shared data (no logic), I'd just use a struct (and embed it in each file type). That would deduplicate the fields without adding additional complexity/overhead.

[whyrusleeping]

Pretty clean refactor, stevens right though, it probably makes sense to just embed a struct here. (unless you want to be able to mock out the inode stuff for some reason in testing)

[schomatis]

(unless you want to be able to mock out the inode stuff for some reason in testing)

Not really, my main motivation for the interface was to be able to enforce read-only attributes (more as a code clarification feature than to protect inadvertent modifications to the object), but that may not be the most Go idiomatic approach, I'll embed the structure then.

[schomatis]

@overbool Want to take over this one?

This should be ported to the go-mfs repo now and the interface (as suggested above) should be turned to a structure to simplify the code.

[overbool]

@schomatis Yes. I'm also interested in this.

[schomatis]

Great! Ping me if you have any trouble porting the diff.