Case discussion on the EIP process, based on EIP-1900 & EIP-1

Magicians Process Improvement
13

@danfinlay, I do not want us to forget the state in which this discussion is, so I am pressing ahead. Since you seem to not have time, I will make an assumption and answer the question for you.

So, I will assume the first instance is in: ERC-1900: Decentralized Type System for EVM · Issue #1882 · ethereum/EIPs · GitHub

I suggest you pay attention to how clearly you phrase your questions before being unsatisfied with the answer.

The sequence of interactions that resulted in my above phrase is:

One interface can have many implementations, but there doesn’t seem to be any distinction made between the two here. comment

LC: Are you referring to the dType registry interface and implementation or to the type library? comment

No, I’m talking about the distinction between a type definition and an implementation. For example, the ERC20 standard defines some types, which are implemented by a large number of different contracts. Capturing the ability for a type to have many implementations seems like a pretty basic feature to support. comment

If the word types has the exact same meaning in both ERC20 standard defines some types and in ability for a type to have many implementations, then:

  • The ERC20 standard defines functions types and devs can indeed implement the functions as they please.
  • ERC20 function types can be defined & registered as types in dType. Devs can still implement them as they please.

But, I assumed that the problem was with non-function types. And from this perspective, the ERC20 example is a bad example (I was confused because of it).

  • Solidity is statically typed → building a type system on top of it is restrictive → the best solution that we found is one based on structs.
  • when you describe a custom struct with dType, you can generate its implementation → devs are not free to change the implementation, which is an automation feature; but devs are those who propose the type description in the first place.

Therefore, my answer:

LC: Devs have the freedom to implement type helper functions, as long as the required ones are implemented (to be discussed). As for the definition, I am open to other proposals that not necessarily based on structs. I am actually trying to have optional subtypes, that can be stored with map. dType registry will be extended with an additional optionals field in the dType struct & a standardized way to define optionals in the Type Library, but this is not ready yet. Other than this, what can I do more to give more freedom to the implementation comment

I still think you’re not understanding the difference between an interface and an implementation. An interface describes an API for other code to interact with, but not how it’s implemented. What you’re proposing here seems to be more along the lines of a directory of library code.
[…] [the spec] doesn’t make a clear distinction between interfaces and implementations. I wish you luck, but I don’t plan to offer further technical feedback.
comment

At this point I was expecting references to the lines of code that were the culprit (one big reason why we use GitHub & PR reviews) and some pointers as to what can I do to fix them. But here, the assumption was that I do not know the general difference between an interface and an implementation.

I still do not know what the exact problem was. If someone knows exactly, please explain.

LC: I asked you before: “Are you referring to the dType registry interface and implementation or to the type library?”, to which you answered with “No, I’m talking about the distinction between a type definition and an implementation”. I suggest you pay attention to how clearly you phrase your questions before being unsatisfied with the answer.
I thought it was clear that this ERC aims to both:

So, regarding this interface-implementation criticism, the status was:

  • comparison with ERC20, which is a different type of standard
  • no reference to any lines of code/spec
  • no code/spec examples
  • this criticism was used as one of the reasons for stopping any further technical feedback

Considering the above, do you consider my phrase: “I suggest you pay attention to how clearly you phrase your questions before being unsatisfied with the answer.” as being untrue? Did I not point out the exact problem that I was facing?

If I become aware of a problem, I will voice it - it is the only way to help the communication advance. Overlooking makes me feel like a hypocrite and it does not help any discussion party understand or improve.

@danfinlay, if you think my comment is coming off as unwarranted hostility, please help me rephrase it.

@Arachnid, if you think I misunderstood your quoted words from above or if you have any material that I overlooked, let me know.