Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

create_with_code_of() does not execute __init__ #773

Closed
haydenadams opened this issue Apr 10, 2018 · 9 comments · Fixed by #2895
Closed

create_with_code_of() does not execute __init__ #773

haydenadams opened this issue Apr 10, 2018 · 9 comments · Fixed by #2895
Labels
bug Bug that shouldn't change language semantics when fixed. VIP: Discussion Used to denote VIPs and more complex issues that are waiting discussion in a meeting

Comments

@haydenadams
Copy link

  • vyper Version: 0.0.4
  • pyethereum Version: 2.3.1
  • OS: macOS
  • Python Version: 3.6.4

What's your issue about?

My post might be unnecessary if #649 is going to be the standard factory pattern.

I'm working on a factory contract that uses create_with_code_of() to launch exchange contracts.

screen shot 2018-04-10 at 4 17 01 pm

Ideally I want the contract that is launched to know the address of the factory. Since create_with_code_of() does not support passing arguments, I tried setting it in the constructor of the exchange:

screen shot 2018-04-10 at 3 19 21 pm

unfortunately, this does not work:

screen shot 2018-04-10 at 4 19 59 pm

How can it be fixed?

Allow contracts created using create_with_code_of() to recognize msg.sender in the constructor.

Or not if #649 is implemented

Or I'm missing something/there is a better factory pattern I should be using that allows passing parameters?

Cute Animal Picture

cute-kittens-67-57b32a998544a__6051

@jacqueswww
Copy link
Contributor

jacqueswww commented Apr 11, 2018

@haydenadams I will have to dig deeper exactly what's wrong. Could it be that the init code isn't ever executed?

@jacqueswww jacqueswww added the bug Bug that shouldn't change language semantics when fixed. label Apr 11, 2018
@haydenadams
Copy link
Author

@jacqueswww Tried setting something else in init and it returned 0. As far as I can tell, init is never executed in create_with_code_of()

@jacqueswww
Copy link
Contributor

That's what I suspected, basically the init code isn't part of the runtime code on chain. We'll have to figure out a new function or extension of the existing function that allows you to scrape the init code.

@jacqueswww
Copy link
Contributor

In the meantime you can build a fake init function with a boolean that can only be called once :-P

@haydenadams
Copy link
Author

Makes sense, thanks! Already implemented that as a temporary solution.

@haydenadams haydenadams changed the title contracts created using create_with_code_of() don't recognize msg.sender in the constructor create_with_code_of() does not execute __init__ Apr 11, 2018
@jacqueswww jacqueswww added the VIP: Discussion Used to denote VIPs and more complex issues that are waiting discussion in a meeting label Apr 23, 2018
@haydenadams
Copy link
Author

In my current solution, the factory does a raw_call() on the new contract immediately after calling create_with_code_of().

Factory
screen shot 2018-04-23 at 4 30 55 pm

Exchange
screen shot 2018-04-23 at 4 31 25 pm

Since the contract creation and raw_call are done in the same function, and setup() can only be called once, it essentially functions as a constructor.

@haydenadams
Copy link
Author

haydenadams commented Jul 18, 2019

@jacqueswww

That's what I suspected, basically the init code isn't part of the runtime code on chain. We'll have to figure out a new function or extension of the existing function that allows you to scrape the init code.

btw b/c of this, Unisocks classic was able to verify on etherscan with this code:
https://etherscan.io/address/0xf7a5a8a95491ec170738434963b649671b563b88#code

despite their init function being different.

@fubuloubu
Copy link
Member

Unisocks classic

🤣🤣🤣

@haydenadams
Copy link
Author

Nice!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Bug that shouldn't change language semantics when fixed. VIP: Discussion Used to denote VIPs and more complex issues that are waiting discussion in a meeting
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants