Closed davidyuk closed 1 year ago
I've already tried that implementation, it does not fit the lib architecture. I'd rather ask the upstream (ACI implementation) to provide a way to distinguish it.
We had short chart with @radrow that led to a conclusion that std libs are indistinguishable from any other types/libs (There is no native Set type).
The mapping in this library is only for better DX, thus it's simple name based implementation, the proposed changed are de-facto reimplementing (hardcoding) the type definitions in this library. There are more types than the set as well.
Given the above, I'm closing this issue as wontfix, until some of the above changes.
Originally raised in https://github.com/aeternity/aepp-calldata-js/pull/127#discussion_r845009331
While this issue doesn't have a significant impact, this can very confuse a developer in the edge case.
As I understand, currently set type detected by name comparison: https://github.com/aeternity/aepp-calldata-js/blob/d2774ec7af75db6f0b4331d85d410b4e7c561488/src/TypeResolver.js#L108-L110, https://github.com/aeternity/aepp-calldata-js/blob/d2774ec7af75db6f0b4331d85d410b4e7c561488/src/TypeResolver.js#L217-L218 But
Set.set
can have a different definition, the same as other name can be aliased toSet.set
. To solve this I'm proposing to assume every type defined asrecord <name>('a) = { to_map : map('a, unit) }
(Set.aes) a set.I've generated corresponding contracts and ACI:
SetCustom.aes
SetAlias.aes
The generated ACI seems to be enough to detect
Set
by type instead of name.