Contract accepting an ANY type
Clash Royale CLAN TAG#URR8PPP
A contract that is upgradable would benefit from being able to accept ANY type, and forward that type to the current app contract based on how that ANY type parses. For example, a request might be sent to a contract which defines the current app contract, and the logic would be controlled by that contract. This would allow an app to have the same contract and have that contract choose where the request is sent. Is there consideration for an ANY type or a way that contracts might be made upgradable and fulfill this requirement? If not, is there a workaround
Perhaps ANY type is too liberal, but making a contract take (pair string (pair ... (pair ... ...)))
etc.. and having storage maintain an address to generalize the contract in preparation for additional methods does feel like a kludge. I will note that a version of this technique has been used in Unix, so perhaps not as bad as I make it sound.
michelson
add a comment |
A contract that is upgradable would benefit from being able to accept ANY type, and forward that type to the current app contract based on how that ANY type parses. For example, a request might be sent to a contract which defines the current app contract, and the logic would be controlled by that contract. This would allow an app to have the same contract and have that contract choose where the request is sent. Is there consideration for an ANY type or a way that contracts might be made upgradable and fulfill this requirement? If not, is there a workaround
Perhaps ANY type is too liberal, but making a contract take (pair string (pair ... (pair ... ...)))
etc.. and having storage maintain an address to generalize the contract in preparation for additional methods does feel like a kludge. I will note that a version of this technique has been used in Unix, so perhaps not as bad as I make it sound.
michelson
I mention ANY type because it is used in protobuf
– Rob
Mar 12 at 8:04
add a comment |
A contract that is upgradable would benefit from being able to accept ANY type, and forward that type to the current app contract based on how that ANY type parses. For example, a request might be sent to a contract which defines the current app contract, and the logic would be controlled by that contract. This would allow an app to have the same contract and have that contract choose where the request is sent. Is there consideration for an ANY type or a way that contracts might be made upgradable and fulfill this requirement? If not, is there a workaround
Perhaps ANY type is too liberal, but making a contract take (pair string (pair ... (pair ... ...)))
etc.. and having storage maintain an address to generalize the contract in preparation for additional methods does feel like a kludge. I will note that a version of this technique has been used in Unix, so perhaps not as bad as I make it sound.
michelson
A contract that is upgradable would benefit from being able to accept ANY type, and forward that type to the current app contract based on how that ANY type parses. For example, a request might be sent to a contract which defines the current app contract, and the logic would be controlled by that contract. This would allow an app to have the same contract and have that contract choose where the request is sent. Is there consideration for an ANY type or a way that contracts might be made upgradable and fulfill this requirement? If not, is there a workaround
Perhaps ANY type is too liberal, but making a contract take (pair string (pair ... (pair ... ...)))
etc.. and having storage maintain an address to generalize the contract in preparation for additional methods does feel like a kludge. I will note that a version of this technique has been used in Unix, so perhaps not as bad as I make it sound.
michelson
michelson
asked Mar 12 at 8:00
RobRob
3607
3607
I mention ANY type because it is used in protobuf
– Rob
Mar 12 at 8:04
add a comment |
I mention ANY type because it is used in protobuf
– Rob
Mar 12 at 8:04
I mention ANY type because it is used in protobuf
– Rob
Mar 12 at 8:04
I mention ANY type because it is used in protobuf
– Rob
Mar 12 at 8:04
add a comment |
2 Answers
2
active
oldest
votes
If you must, you can use bytes
and PACK
/UNPACK
: http://tezos.gitlab.io/mainnet/whitedoc/michelson.html#operations-on-bytes
For 'any storage', you can use pair (big_map bytes bytes) ...
, with your own conventions for the keys (perhaps packed pair/list/etc expressions with some string tags).
When doing these things you abandon some benefits of the type system.
There is currently no support or convention for 'tagged' data. When using bytes
as an 'any' type, the consumer (who will UNPACK
) should somehow already know the expected Michelson type and its particular semantics: the bytes only encode a Micheline expression, with no type (and no annotations).
But perhaps you could make a contract accept(Pair string bytes)
where string is the method name. I think that would work for creating an upgradable contract.
– Rob
Mar 12 at 20:17
add a comment |
If you just want to dispatch to a specified set of methods, who ses types are known, what you are looking for is the « alternative » type or sum type, where the value is (Left (Right (... )), ie a path of Left and Right constructors to the final type of the method.
Otherwise, if you want a completely generic version, allowing addition of new methods and types in the future, you can use UNPACK to extract the argument from a generic Bytes type. This way, all the methods are Bytes method, and you can dispatch using another argument (a hash of the method prototype for example). Though it solves your problem, it means that there is no static control any more at the boundaries of your contract : your code might contain an error, that will only be detected when the UNPACK will fail, maybe making your contract completely useless.
Very Interesting! Could you provide an example?
– Rob
Mar 12 at 20:02
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "698"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftezos.stackexchange.com%2fquestions%2f748%2fcontract-accepting-an-any-type%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
If you must, you can use bytes
and PACK
/UNPACK
: http://tezos.gitlab.io/mainnet/whitedoc/michelson.html#operations-on-bytes
For 'any storage', you can use pair (big_map bytes bytes) ...
, with your own conventions for the keys (perhaps packed pair/list/etc expressions with some string tags).
When doing these things you abandon some benefits of the type system.
There is currently no support or convention for 'tagged' data. When using bytes
as an 'any' type, the consumer (who will UNPACK
) should somehow already know the expected Michelson type and its particular semantics: the bytes only encode a Micheline expression, with no type (and no annotations).
But perhaps you could make a contract accept(Pair string bytes)
where string is the method name. I think that would work for creating an upgradable contract.
– Rob
Mar 12 at 20:17
add a comment |
If you must, you can use bytes
and PACK
/UNPACK
: http://tezos.gitlab.io/mainnet/whitedoc/michelson.html#operations-on-bytes
For 'any storage', you can use pair (big_map bytes bytes) ...
, with your own conventions for the keys (perhaps packed pair/list/etc expressions with some string tags).
When doing these things you abandon some benefits of the type system.
There is currently no support or convention for 'tagged' data. When using bytes
as an 'any' type, the consumer (who will UNPACK
) should somehow already know the expected Michelson type and its particular semantics: the bytes only encode a Micheline expression, with no type (and no annotations).
But perhaps you could make a contract accept(Pair string bytes)
where string is the method name. I think that would work for creating an upgradable contract.
– Rob
Mar 12 at 20:17
add a comment |
If you must, you can use bytes
and PACK
/UNPACK
: http://tezos.gitlab.io/mainnet/whitedoc/michelson.html#operations-on-bytes
For 'any storage', you can use pair (big_map bytes bytes) ...
, with your own conventions for the keys (perhaps packed pair/list/etc expressions with some string tags).
When doing these things you abandon some benefits of the type system.
There is currently no support or convention for 'tagged' data. When using bytes
as an 'any' type, the consumer (who will UNPACK
) should somehow already know the expected Michelson type and its particular semantics: the bytes only encode a Micheline expression, with no type (and no annotations).
If you must, you can use bytes
and PACK
/UNPACK
: http://tezos.gitlab.io/mainnet/whitedoc/michelson.html#operations-on-bytes
For 'any storage', you can use pair (big_map bytes bytes) ...
, with your own conventions for the keys (perhaps packed pair/list/etc expressions with some string tags).
When doing these things you abandon some benefits of the type system.
There is currently no support or convention for 'tagged' data. When using bytes
as an 'any' type, the consumer (who will UNPACK
) should somehow already know the expected Michelson type and its particular semantics: the bytes only encode a Micheline expression, with no type (and no annotations).
answered Mar 12 at 9:47
TomTom
1,486216
1,486216
But perhaps you could make a contract accept(Pair string bytes)
where string is the method name. I think that would work for creating an upgradable contract.
– Rob
Mar 12 at 20:17
add a comment |
But perhaps you could make a contract accept(Pair string bytes)
where string is the method name. I think that would work for creating an upgradable contract.
– Rob
Mar 12 at 20:17
But perhaps you could make a contract accept
(Pair string bytes)
where string is the method name. I think that would work for creating an upgradable contract.– Rob
Mar 12 at 20:17
But perhaps you could make a contract accept
(Pair string bytes)
where string is the method name. I think that would work for creating an upgradable contract.– Rob
Mar 12 at 20:17
add a comment |
If you just want to dispatch to a specified set of methods, who ses types are known, what you are looking for is the « alternative » type or sum type, where the value is (Left (Right (... )), ie a path of Left and Right constructors to the final type of the method.
Otherwise, if you want a completely generic version, allowing addition of new methods and types in the future, you can use UNPACK to extract the argument from a generic Bytes type. This way, all the methods are Bytes method, and you can dispatch using another argument (a hash of the method prototype for example). Though it solves your problem, it means that there is no static control any more at the boundaries of your contract : your code might contain an error, that will only be detected when the UNPACK will fail, maybe making your contract completely useless.
Very Interesting! Could you provide an example?
– Rob
Mar 12 at 20:02
add a comment |
If you just want to dispatch to a specified set of methods, who ses types are known, what you are looking for is the « alternative » type or sum type, where the value is (Left (Right (... )), ie a path of Left and Right constructors to the final type of the method.
Otherwise, if you want a completely generic version, allowing addition of new methods and types in the future, you can use UNPACK to extract the argument from a generic Bytes type. This way, all the methods are Bytes method, and you can dispatch using another argument (a hash of the method prototype for example). Though it solves your problem, it means that there is no static control any more at the boundaries of your contract : your code might contain an error, that will only be detected when the UNPACK will fail, maybe making your contract completely useless.
Very Interesting! Could you provide an example?
– Rob
Mar 12 at 20:02
add a comment |
If you just want to dispatch to a specified set of methods, who ses types are known, what you are looking for is the « alternative » type or sum type, where the value is (Left (Right (... )), ie a path of Left and Right constructors to the final type of the method.
Otherwise, if you want a completely generic version, allowing addition of new methods and types in the future, you can use UNPACK to extract the argument from a generic Bytes type. This way, all the methods are Bytes method, and you can dispatch using another argument (a hash of the method prototype for example). Though it solves your problem, it means that there is no static control any more at the boundaries of your contract : your code might contain an error, that will only be detected when the UNPACK will fail, maybe making your contract completely useless.
If you just want to dispatch to a specified set of methods, who ses types are known, what you are looking for is the « alternative » type or sum type, where the value is (Left (Right (... )), ie a path of Left and Right constructors to the final type of the method.
Otherwise, if you want a completely generic version, allowing addition of new methods and types in the future, you can use UNPACK to extract the argument from a generic Bytes type. This way, all the methods are Bytes method, and you can dispatch using another argument (a hash of the method prototype for example). Though it solves your problem, it means that there is no static control any more at the boundaries of your contract : your code might contain an error, that will only be detected when the UNPACK will fail, maybe making your contract completely useless.
answered Mar 12 at 9:51
lefessan♦lefessan
3,042522
3,042522
Very Interesting! Could you provide an example?
– Rob
Mar 12 at 20:02
add a comment |
Very Interesting! Could you provide an example?
– Rob
Mar 12 at 20:02
Very Interesting! Could you provide an example?
– Rob
Mar 12 at 20:02
Very Interesting! Could you provide an example?
– Rob
Mar 12 at 20:02
add a comment |
Thanks for contributing an answer to Tezos Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftezos.stackexchange.com%2fquestions%2f748%2fcontract-accepting-an-any-type%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I mention ANY type because it is used in protobuf
– Rob
Mar 12 at 8:04