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

Branch autogen entrypoint #67

Merged
merged 9 commits into from Jun 23, 2019

Conversation

4 participants
@lightszero
Copy link
Member

commented Jun 21, 2019

if you do not write a Main function in smart contract.
now we can add one automatic:

    class Contract_autoentrypoint : SmartContract.Framework.SmartContract
    {
        //there is no main here, it can be auto generation.
        //object Main(string name,object[])
        //{
        //    if(name=="call01")
        //    {
        //        return call01();
        //    }
        //    if(name=="call02")
        //    {
        //        call02(_params[0],params[1]);
        //        return 0; //null or "" or 0 or false , if call02 is void,will add return 0;
        //    }
        //    throw //if no method was found,make vm fault.
        //}
        public static byte[] call01()
        {
            var nb = new byte[] { 1, 2, 3, 4 };
            return nb;
        }
        public static void call02(string a,int b)
        {
            Neo.SmartContract.Framework.Services.Neo.Runtime.Log(a);
        }
    }

lightszero added some commits Jun 21, 2019

can call funcs
 with params and without params.
 return void or return others.
@igormcoelho
Copy link
Contributor

left a comment

This idea is really good. Congratulation Lights.

I reviewed most of this PR in the other PR... but I didn't like that one 😂 hahaha we need testing in both ways: standard and non-standard entrypoints.

@shargon

This comment has been minimized.

Copy link
Member

commented Jun 22, 2019

Very nice work @lightszero ! i love it! my only concern is about verification, how we can deal with this, i think that it should return false in verification.

@shargon

This comment has been minimized.

Copy link
Member

commented Jun 22, 2019

What about...

public static bool onVerification()
{
  // Logic here?
  return false;
}
@lightszero

This comment has been minimized.

Copy link
Member Author

commented Jun 22, 2019

This idea is really good. Congratulation Lights.

I reviewed most of this PR in the other PR... but I didn't like that one 😂 hahaha we need testing in both ways: standard and non-standard entrypoints.

this idea is from eric.

@lightszero

This comment has been minimized.

Copy link
Member Author

commented Jun 22, 2019

Very nice work @lightszero ! i love it! my only concern is about verification, how we can deal with this, i think that it should return false in verification.

err...,that is a question.

as eric said all neo3 contract is Main(string,object[])

but how about verification?
@erikzhang

@igormcoelho

This comment has been minimized.

Copy link
Contributor

commented Jun 22, 2019

Congratulations for the idea @erikzhang 😂

if all is unified, fine.

I think your case is not a problem Shargon, because the method would push0 , and conversion already knows its a bool type, and ot would be returned normally. The only "edge" case is a void metgod, which is being treated as "return false", right lights?

This one is just when you dont declare your main, so it creates for you. The other PR is more problematic.

lightszero added some commits Jun 23, 2019

add testmethod for standard Contract
//old test method still keep
StackItem[] _params = new StackItem[] { "call02", new StackItem[] { "hello", 33 } };
var resultstack = testengine.ExecuteTestCase(_params);

//new test method
var result = testengine.ExecuteTestCaseStandard("call02", “hello",33);

//new test method(another way)
var result = testengine.GetMethod("call02").Run("hello",33);
@lightszero

This comment has been minimized.

Copy link
Member Author

commented Jun 23, 2019

I think we can merge this first.
and discuss about verification more.

maybe add some attribute to help compiler like

[Trigger(Verification=false,Application=true)]
void call01()
{
///
}
@shargon

This comment has been minimized.

Copy link
Member

commented Jun 23, 2019

I was thinking exactly in this, an attribute!

@lightszero lightszero merged commit 3181fe2 into master Jun 23, 2019

2 checks passed

Travis CI - Branch Build Passed
Details
Travis CI - Pull Request Build Passed
Details

@lightszero lightszero deleted the Branch_autogen_entrypoint branch Jun 23, 2019

@erikzhang

This comment has been minimized.

Copy link
Member

commented Jun 23, 2019

For verification, you can write the Main() function manually.

@erikzhang

This comment has been minimized.

Copy link
Member

commented Jun 23, 2019

We should also update the templates.

@shargon

This comment has been minimized.

Copy link
Member

commented Jun 23, 2019

For verification, you can write the Main() function manually.

But by default, should return false

@igormcoelho

This comment has been minimized.

Copy link
Contributor

commented Jun 23, 2019

I think that unused functions should FAULT on Application. If we have exception handling, this would help creating "inheritance". I don't know the plan yet, but pehaps an "special" FAULT state... like FAULT cause Exception="method not found".

@lightszero

This comment has been minimized.

Copy link
Member Author

commented Jun 24, 2019

already fault,but fault is not have param in neovm. we can not set a fault reason.

@igormcoelho

This comment has been minimized.

Copy link
Contributor

commented Jun 24, 2019

I think that FAULT reason is more important for a better Exception handling... in the future.

@igormcoelho

This comment has been minimized.

Copy link
Contributor

commented Jun 24, 2019

Just to clarify, the problem is the THROW itself... sometimes you want to invoke something, and if it fails, you proceed with other alternative. So, we actually need exception handling. I'm just mentioning here because it would be useful together with this feature here... but perhaps it's time to start thinking on strategies to allow exception handling on vm.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.