Contract accepting an ANY type

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












3















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.










share|improve this question






















  • I mention ANY type because it is used in protobuf

    – Rob
    Mar 12 at 8:04















3















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.










share|improve this question






















  • I mention ANY type because it is used in protobuf

    – Rob
    Mar 12 at 8:04













3












3








3








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.










share|improve this question














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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










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

















  • 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










2 Answers
2






active

oldest

votes


















3














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).






share|improve this answer























  • 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



















2














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.






share|improve this answer























  • Very Interesting! Could you provide an example?

    – Rob
    Mar 12 at 20:02











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
);



);













draft saved

draft discarded


















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









3














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).






share|improve this answer























  • 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
















3














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).






share|improve this answer























  • 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














3












3








3







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).






share|improve this answer













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).







share|improve this answer












share|improve this answer



share|improve this answer










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


















  • 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












2














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.






share|improve this answer























  • Very Interesting! Could you provide an example?

    – Rob
    Mar 12 at 20:02















2














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.






share|improve this answer























  • Very Interesting! Could you provide an example?

    – Rob
    Mar 12 at 20:02













2












2








2







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.






share|improve this answer













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.







share|improve this answer












share|improve this answer



share|improve this answer










answered Mar 12 at 9:51









lefessanlefessan

3,042522




3,042522












  • 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





Very Interesting! Could you provide an example?

– Rob
Mar 12 at 20:02

















draft saved

draft discarded
















































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.




draft saved


draft discarded














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





















































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






Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay