Remove WollokNativeLobby. Model wollok.lang.Program class

[javierfernandes]

The native lobby is the "this" object of a wollok program. As programs are special constructions. We should probably need to model de wollok.lang.Program class and then change the interpreter so that when it finds a WProgram it will instantiate that class. In that way it will be just treated as a regular object.

This will simplify the intepreter EvaluationContext model.

[npasserini]

Why a class and not an object On Dec 15, 2015 8:28 PM, "javierfernandes" [email protected] wrote:

The native lobby is the "this" object of a wollok program. As programs are special constructions. We should probably need to model de wollok.lang.Program class and then change the interpreter so that when it finds a WProgram it will instantiate that class. In that way it will be just treated as a regular object.

This will simplify the intepreter EvaluationContext model.

— Reply to this email directly or view it on GitHub https://github.com/uqbar-project/wollok/issues/498.

[javierfernandes]

Yes, it could be. I didn't think about it much. Just arosed while documenting. With object you mean a regular anonymous object and not a predefined wko right? I thought about having a class to have there documented any behavior we want a program to have. But i think that changing it to an object is the simplest change that will simplify de interpreter quickly El dic 15, 2015 9:57 PM, "Nico Passerini" [email protected] escribió:

Why a class and not an object On Dec 15, 2015 8:28 PM, "javierfernandes" [email protected] wrote:

The native lobby is the "this" object of a wollok program. As programs are special constructions. We should probably need to model de wollok.lang.Program class and then change the interpreter so that when it finds a WProgram it will instantiate that class. In that way it will be just treated as a regular object.

This will simplify the intepreter EvaluationContext model.

— Reply to this email directly or view it on GitHub https://github.com/uqbar-project/wollok/issues/498.

— Reply to this email directly or view it on GitHub https://github.com/uqbar-project/wollok/issues/498#issuecomment-164949036 .

[npasserini]

Nope, I was thinking that program could be just a wko, but maybe I'm wrong.

On Tue, Dec 15, 2015 at 10:17 PM, javierfernandes [email protected] wrote:

Yes, it could be. I didn't think about it much. Just arosed while documenting. With object you mean a regular anonymous object and not a predefined wko right? I thought about having a class to have there documented any behavior we want a program to have. But i think that changing it to an object is the simplest change that will simplify de interpreter quickly El dic 15, 2015 9:57 PM, "Nico Passerini" [email protected] escribió:

Why a class and not an object On Dec 15, 2015 8:28 PM, "javierfernandes" [email protected] wrote:

The native lobby is the "this" object of a wollok program. As programs are special constructions. We should probably need to model de wollok.lang.Program class and then change the interpreter so that when it finds a WProgram it will instantiate that class. In that way it will be just treated as a regular object.

This will simplify the intepreter EvaluationContext model.

— Reply to this email directly or view it on GitHub https://github.com/uqbar-project/wollok/issues/498.

— Reply to this email directly or view it on GitHub < https://github.com/uqbar-project/wollok/issues/498#issuecomment-164949036>

.

— Reply to this email directly or view it on GitHub https://github.com/uqbar-project/wollok/issues/498#issuecomment-164952536 .

[javierfernandes]

Yeah, just that we don't want it to be accesible from anywhere.

Actually WKO's are just the same as objectliterals just that they are added to the global scope. So it's the same

On Wed, Dec 16, 2015 at 9:53 AM, Nico Passerini [email protected] wrote:

Nope, I was thinking that program could be just a wko, but maybe I'm wrong.

On Tue, Dec 15, 2015 at 10:17 PM, javierfernandes < [email protected]> wrote:

Yes, it could be. I didn't think about it much. Just arosed while documenting. With object you mean a regular anonymous object and not a predefined wko right? I thought about having a class to have there documented any behavior we want a program to have. But i think that changing it to an object is the simplest change that will simplify de interpreter quickly El dic 15, 2015 9:57 PM, "Nico Passerini" [email protected] escribió:

Why a class and not an object On Dec 15, 2015 8:28 PM, "javierfernandes" [email protected] wrote:

The native lobby is the "this" object of a wollok program. As programs are special constructions. We should probably need to model de wollok.lang.Program class and then change the interpreter so that when it finds a WProgram it will instantiate that class. In that way it will be just treated as a regular object.

This will simplify the intepreter EvaluationContext model.

— Reply to this email directly or view it on GitHub https://github.com/uqbar-project/wollok/issues/498.

— Reply to this email directly or view it on GitHub <

https://github.com/uqbar-project/wollok/issues/498#issuecomment-164949036>

.

— Reply to this email directly or view it on GitHub < https://github.com/uqbar-project/wollok/issues/498#issuecomment-164952536>

.

— Reply to this email directly or view it on GitHub https://github.com/uqbar-project/wollok/issues/498#issuecomment-165096442 .

[npasserini]

Ok, right. Also I was thinking that you might have multiple programs in the same project, so if you tried to make them wkos you might produce a colision.

So, I agree it should be a class.

On Wed, Dec 16, 2015 at 10:15 AM, javierfernandes [email protected] wrote:

Yeah, just that we don't want it to be accesible from anywhere.

Actually WKO's are just the same as objectliterals just that they are added to the global scope. So it's the same

On Wed, Dec 16, 2015 at 9:53 AM, Nico Passerini [email protected] wrote:

Nope, I was thinking that program could be just a wko, but maybe I'm wrong.

On Tue, Dec 15, 2015 at 10:17 PM, javierfernandes < [email protected]> wrote:

Yes, it could be. I didn't think about it much. Just arosed while documenting. With object you mean a regular anonymous object and not a predefined wko right? I thought about having a class to have there documented any behavior we want a program to have. But i think that changing it to an object is the simplest change that will simplify de interpreter quickly El dic 15, 2015 9:57 PM, "Nico Passerini" [email protected] escribió:

Why a class and not an object On Dec 15, 2015 8:28 PM, "javierfernandes" <[email protected]

wrote:

The native lobby is the "this" object of a wollok program. As programs are special constructions. We should probably need to model de wollok.lang.Program class and then change the interpreter so that when it finds a WProgram it will instantiate that class. In that way it will be just treated as a regular object.

This will simplify the intepreter EvaluationContext model.

— Reply to this email directly or view it on GitHub https://github.com/uqbar-project/wollok/issues/498.

— Reply to this email directly or view it on GitHub <

https://github.com/uqbar-project/wollok/issues/498#issuecomment-164949036>

.

— Reply to this email directly or view it on GitHub <

https://github.com/uqbar-project/wollok/issues/498#issuecomment-164952536>

.

— Reply to this email directly or view it on GitHub < https://github.com/uqbar-project/wollok/issues/498#issuecomment-165096442>

.

— Reply to this email directly or view it on GitHub https://github.com/uqbar-project/wollok/issues/498#issuecomment-165100634 .

[javierfernandes]

But program have a name. So we could treat them as WKOs in terms of cross-references. So maybe the grammar will also change.

Example

program pepitaFlights {
}

Program class

class Program {
    method isRunning() native
    method name() native
    method console() native  // ?
    // etc
}

Another file used by the program

// ...
pepita.isRunning() 
// ...

I suspect it is not a good practice to use the program from a class / wko. But anyway.

We could also have

object System {
     method getCurrentProgram() native
}

[javierfernandes]

This will also solve the program with "weird" stack trace element for programs

wollok.lang.MessageNotUnderstoodException: a AsustadorNato[nivelMotivacion=100, edad=25, puntosTerrorInnatos=200] does not understand cantina()
    at wollok.lang.Object.messageNotUnderstood(name,parameters) [/wollok.wlk:151]
    at wollok.example.monstersinc.Monster.scare(boy) [/wollok.wlk:151]
    at  [/workspace.wpgm:23]

Check last line, from the program, doesn't have a method involcation. In this case it should be something like:

wollok.lang.MessageNotUnderstoodException: a AsustadorNato[nivelMotivacion=100, edad=25, puntosTerrorInnatos=200] does not understand cantina()
    at wollok.lang.Object.messageNotUnderstood(name,parameters) [/wollok.wlk:151]
    at wollok.example.monstersinc.Monster.scare(boy) [/wollok.wlk:151]
    at wollok.lang.Program.execute() [/workspace.wpgm:23]

[npasserini]

I do not like wollok.lang.Program.execute() because users do not know about a Program object.

I would prefer to use the name/package of the file and something like , for example: wollok.example.monstersinc.

On Thu, Jul 21, 2016 at 4:09 PM, javierfernandes [email protected] wrote:

This will also solve the program with "weird" stack trace element for programs

wollok.lang.MessageNotUnderstoodException: a AsustadorNato[nivelMotivacion=100, edad=25, puntosTerrorInnatos=200] does not understand cantina() at wollok.lang.Object.messageNotUnderstood(name,parameters) [/wollok.wlk:151] at wollok.example.monstersinc.Monster.scare(boy) [/wollok.wlk:151] at [/workspace.wpgm:23]

Check last line, from the program, doesn't have a method involcation. In this case it should be something like:

wollok.lang.MessageNotUnderstoodException: a AsustadorNato[nivelMotivacion=100, edad=25, puntosTerrorInnatos=200] does not understand cantina() at wollok.lang.Object.messageNotUnderstood(name,parameters) [/wollok.wlk:151] at wollok.example.monstersinc.Monster.scare(boy) [/wollok.wlk:151] at wollok.lang.Program.execute() [/workspace.wpgm:23]

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/uqbar-project/wollok/issues/498#issuecomment-234264917, or mute the thread https://github.com/notifications/unsubscribe-auth/AEa1Od1uOvIEbmpARTk_6o7B6hgKIDO-ks5qX32ogaJpZM4G2Feq .

[javierfernandes]

Yes. Just that in that case that part of the stack trace will be inconsistent with other stack that are all method callls. That would make difficult implementing stack hypeelinks an navigation for example. Maybe assuming that a program creates a class inheriring from program but still like a methof call

wollok.example.monsterinc.myprogram.execute() ??

Navigating that will take you to the program.

El Friday, July 22, 2016, Nico Passerini [email protected] escribió:

I do not like wollok.lang.Program.execute() because users do not know about a Program object.

I would prefer to use the name/package of the file and something like , for example: wollok.example.monstersinc.

On Thu, Jul 21, 2016 at 4:09 PM, javierfernandes <[email protected] javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

This will also solve the program with "weird" stack trace element for programs

wollok.lang.MessageNotUnderstoodException: a AsustadorNato[nivelMotivacion=100, edad=25, puntosTerrorInnatos=200] does not understand cantina() at wollok.lang.Object.messageNotUnderstood(name,parameters) [/wollok.wlk:151] at wollok.example.monstersinc.Monster.scare(boy) [/wollok.wlk:151] at [/workspace.wpgm:23]

Check last line, from the program, doesn't have a method involcation. In this case it should be something like:

wollok.lang.MessageNotUnderstoodException: a AsustadorNato[nivelMotivacion=100, edad=25, puntosTerrorInnatos=200] does not understand cantina() at wollok.lang.Object.messageNotUnderstood(name,parameters) [/wollok.wlk:151] at wollok.example.monstersinc.Monster.scare(boy) [/wollok.wlk:151] at wollok.lang.Program.execute() [/workspace.wpgm:23]

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/uqbar-project/wollok/issues/498#issuecomment-234264917 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AEa1Od1uOvIEbmpARTk_6o7B6hgKIDO-ks5qX32ogaJpZM4G2Feq

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/uqbar-project/wollok/issues/498#issuecomment-234667506, or mute the thread https://github.com/notifications/unsubscribe-auth/AEORWDYrUO5PZ6jELvZiguc7Sg_i2Aytks5qYT1NgaJpZM4G2Feq .

[npasserini]

In fact it is not a method call... it is a conscious decision, I have always hated to be enforced to write things like java main program, it enforces a naming convention, which is difficult to follow. If it is special, lets make it special. So I would prefer to be consistent with that decision.

The same happens with tests.

Anyway, internally nor a program nor a test are methods, so navigation will eventually have to handle this situations specifically.

Maybe we could negotitate packageName.fileName.program (I would prefer without parenthesis). (Yes I can negotiate the parenthesis, but they do not appear in the real program... either way, program does appear and execute no, so I will vote for program).

and for tests? packageName.fileName."test description" packageName.fileName.test("test description") packageName.fileName.test(test description)

I do not know, this is more difficult.

On Sat, Jul 23, 2016 at 1:20 AM, javierfernandes [email protected] wrote:

Yes. Just that in that case that part of the stack trace will be inconsistent with other stack that are all method callls. That would make difficult implementing stack hypeelinks an navigation for example. Maybe assuming that a program creates a class inheriring from program but still like a methof call

wollok.example.monsterinc.myprogram.execute() ??

Navigating that will take you to the program.

El Friday, July 22, 2016, Nico Passerini [email protected] escribió:

I do not like wollok.lang.Program.execute() because users do not know about a Program object.

I would prefer to use the name/package of the file and something like , for example: wollok.example.monstersinc.

On Thu, Jul 21, 2016 at 4:09 PM, javierfernandes < [email protected] javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

This will also solve the program with "weird" stack trace element for programs

wollok.lang.MessageNotUnderstoodException: a AsustadorNato[nivelMotivacion=100, edad=25, puntosTerrorInnatos=200] does not understand cantina() at wollok.lang.Object.messageNotUnderstood(name,parameters) [/wollok.wlk:151] at wollok.example.monstersinc.Monster.scare(boy) [/wollok.wlk:151] at [/workspace.wpgm:23]

Check last line, from the program, doesn't have a method involcation. In this case it should be something like:

wollok.lang.MessageNotUnderstoodException: a AsustadorNato[nivelMotivacion=100, edad=25, puntosTerrorInnatos=200] does not understand cantina() at wollok.lang.Object.messageNotUnderstood(name,parameters) [/wollok.wlk:151] at wollok.example.monstersinc.Monster.scare(boy) [/wollok.wlk:151] at wollok.lang.Program.execute() [/workspace.wpgm:23]

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/uqbar-project/wollok/issues/498#issuecomment-234264917

, or mute the thread <

https://github.com/notifications/unsubscribe-auth/AEa1Od1uOvIEbmpARTk_6o7B6hgKIDO-ks5qX32ogaJpZM4G2Feq

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/uqbar-project/wollok/issues/498#issuecomment-234667506 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AEORWDYrUO5PZ6jELvZiguc7Sg_i2Aytks5qYT1NgaJpZM4G2Feq

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/uqbar-project/wollok/issues/498#issuecomment-234679861, or mute the thread https://github.com/notifications/unsubscribe-auth/AEa1OeXas1HHfJhHSVHGQmcg2rO3o2kZks5qYVA6gaJpZM4G2Feq .