Automatically call entry point #39

New Issue

Closed

opened 2018-08-08 11:21:33 +02:00 by belliash · 3 comments

belliash commented

2018-08-08 11:21:33 +02:00

Owner

Actually all our test scripts contain "new Main();" in order to call for an entry point. This should be invoked automatically by the Interpreter from the PH7_VmByteCodeExec() function.

It should look for a main class, instantiate it, call its constructor if exists. Also it should pass argv as a parameter to the entry point. Some mechanism needs to be implemented to do that. There are two ways:

PH7_VmCallClassMethod() will take one more argument saying that it should NOT check for parameters count and we will pass argv everytime, regardless any argument have been passed to the script or not. Otherwise, Interpreter will throw error.
We have to check how many parameters does entry point take. If it take one parameter, pass argv. If does not take any arguments, do not pass it. if takes more arguments, throw error.

Additionally in scope of this ticket, I would like to discuss:

Which way should we choose to solve above described problem?
Should the entry class be called Main? Or maybe we should rename it to sth else (eg. Program)?
Should we try to launch only constructor, or maybe there should be another method implemented (eg. main())? Thus we could do some pre-tasks in constructor, before Main::main() or Program::main() would be called? This could be resolved respectively

to:

$main = new Main();

$main = new Main();
$main->main();

Actually all our test scripts contain "__new Main();__" in order to call for an entry point. This should be invoked automatically by the Interpreter from the PH7_VmByteCodeExec() function. It should look for a main class, instantiate it, call its constructor if exists. Also it should pass argv as a parameter to the entry point. Some mechanism needs to be implemented to do that. There are two ways: 1. PH7_VmCallClassMethod() will take one more argument saying that it should NOT check for parameters count and we will pass argv everytime, regardless any argument have been passed to the script or not. Otherwise, Interpreter will throw error. 2. We have to check how many parameters does entry point take. If it take one parameter, pass argv. If does not take any arguments, do not pass it. if takes more arguments, throw error. Additionally in scope of this ticket, I would like to discuss: 1. Which way should we choose to solve above described problem? 2. Should the entry class be called Main? Or maybe we should rename it to sth else (eg. Program)? 3. Should we try to launch only constructor, or maybe there should be another method implemented (eg. main())? Thus we could do some pre-tasks in constructor, before Main::main() or Program::main() would be called? This could be resolved respectively to: $main = new Main(); or $main = new Main(); $main->main();

belliash added the

aerscript

label 2018-08-08 11:21:33 +02:00

belliash added the

question

label 2018-08-08 12:04:14 +02:00

likoski commented

2018-08-08 15:25:54 +02:00

Owner

Answering to your questions.

I would say, that it is a good idea to check number of parameters. However, on the other hand, first solution is used in other compilers. For example C/C++ compiler does not verify that. It might depend on implementation, but for sure GCC treats main() as a normal function and allows it to take any amount and any kind of arguments. The mentioned by @belliash check should be done later. The Interpreter should fail if supplied value will not match the variable type. But even this is not verified by other compilers I used to know. If developer make a mistake, the resulting program will cause a segmentation failure. What is more, I think the first solution will be easier to implement. I am not sure if we should do it exactly as described, but I am pretty sure this is the way to follow.
I see no difference. We can even try to use both of them with some precedence.
In my opinion, class constructor should not be used as a program entry. Having some method like main() is more than appreciated. This is also how it works in C#. If we decide to use main() method instead of constructor, I think we could also change the class name from Main to something else, i.e. mentioned Program. This could improve the readability a bit. I am just not sure if it is a good idea to still call constructor then.

Answering to your questions. 1. I would say, that it is a good idea to check number of parameters. However, on the other hand, first solution is used in other compilers. For example C/C++ compiler does not verify that. It might depend on implementation, but for sure GCC treats main() as a normal function and allows it to take any amount and any kind of arguments. The mentioned by @belliash check should be done later. The Interpreter should fail if supplied value will not match the variable type. But even this is not verified by other compilers I used to know. If developer make a mistake, the resulting program will cause a segmentation failure. What is more, I think the first solution will be easier to implement. I am not sure if we should do it exactly as described, but I am pretty sure this is the way to follow. 2. I see no difference. We can even try to use both of them with some precedence. 3. In my opinion, class constructor should not be used as a program entry. Having some method like main() is more than appreciated. This is also how it works in C#. If we decide to use main() method instead of constructor, I think we could also change the class name from Main to something else, i.e. mentioned Program. This could improve the readability a bit. I am just not sure if it is a good idea to still call constructor then.

belliash self-assigned this 2018-08-11 21:09:22 +02:00

belliash commented

2018-08-11 21:09:40 +02:00

Poster

Owner

Will be done in compiler_rework branch.