updated economic metrics to reflect new spec

[samlaf]

Fixes # .

Motivation

Solution

Open questions

[shrimalmadhur]

should it be in operator.go or some utils.go files?

[samlaf]

I put it here because we otherwise have a circular dependency between utils and types...
this types package will require a refactor. I was thinking of putting your operator stuff in types/operator maybe, or something like that. Needs to be thought through how we want to separate utils and types. In some sense I'm thinking we should only have types here and all your operator methods (like Validate) should maybe be functions defined in utils?

[shrimalmadhur]

the reason I added Validate is because it's a part of struct - as in you have to have operator object to call it. you can't call that without creating an object first. It would be confusing to put it in utils.
This function here doesn't require any object to be calling this - that's why it can added independently to utils. That's kind of my thought process in separating types vs utils.

I feel we can have multiple utils based on package too.

[samlaf]

Don't understand your point. You can always turn a method into a function. Your Validate function could also just be written

Validate (operator, ...)

[samlaf]

In any case I can't move it to utils.go because that would create a circular dependency. What's your suggestion here?

[shrimalmadhur]

yea I didn't realize the circular dependency part. okay. I think it's fine here. we maybe have to think of clear separation.

You can always turn a method into a function - I think it's cleaner and very specific that validate is acted on the operator, where utils function can be more generic, like checking an eth address or a valid url vs utilities of our own types. We can think about that separation