Contract accepting an ANY type
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
asked 15 hours ago
RobRob
2986
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
asked 15 hours ago
RobRob
2986
I mention ANY type because it is used in protobuf
– Rob
15 hours ago
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
asked 15 hours ago
RobRob
2986
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 15 hours ago
RobRob
2986
asked 15 hours ago
RobRob
2986
asked 15 hours ago
RobRob
2986
asked 15 hours ago
RobRob
2986
asked 15 hours ago
RobRob
2986
2986
I mention ANY type because it is used in protobuf
– Rob
15 hours ago
add a comment |
I mention ANY type because it is used in protobuf
– Rob
15 hours ago
I mention ANY type because it is used in protobuf
– Rob
15 hours ago
I mention ANY type because it is used in protobuf
– Rob
15 hours ago
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).
answered 13 hours ago
TomTom
89327
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
3 hours ago
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.
answered 13 hours ago
lefessan♦lefessan
2,567522
Very Interesting! Could you provide an example?
– Rob
3 hours ago
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).
answered 13 hours ago
TomTom
89327
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
3 hours ago
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).
answered 13 hours ago
TomTom
89327
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
3 hours ago
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).
answered 13 hours ago
TomTom
89327
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 13 hours ago
TomTom
89327
answered 13 hours ago
TomTom
89327
answered 13 hours ago
TomTom
89327
answered 13 hours ago
TomTom
89327
89327
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
3 hours ago
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
3 hours ago
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
3 hours ago
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
3 hours ago
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.
answered 13 hours ago
lefessan♦lefessan
2,567522
Very Interesting! Could you provide an example?
– Rob
3 hours ago
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.
answered 13 hours ago
lefessan♦lefessan
2,567522
Very Interesting! Could you provide an example?
– Rob
3 hours ago
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.
answered 13 hours ago
lefessan♦lefessan
2,567522
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 13 hours ago
lefessan♦lefessan
2,567522
answered 13 hours ago
lefessan♦lefessan
2,567522
answered 13 hours ago
lefessan♦lefessan
2,567522
answered 13 hours ago
lefessan♦lefessan
2,567522
2,567522
Very Interesting! Could you provide an example?
– Rob
3 hours ago
add a comment |
Very Interesting! Could you provide an example?
– Rob
3 hours ago
Very Interesting! Could you provide an example?
– Rob
3 hours ago
Very Interesting! Could you provide an example?
– Rob
3 hours ago
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
15 hours ago