Should be a way to remove an object from the board.

[javierfernandes]

For example for pacman I want to remove the cherry when pacman hits it

Currently I didn't find a way.

@PalumboN @Juancete @charlyraffellini is there any way ?

[PalumboN]

No, it isn't :disappointed:

[PalumboN]

How do you like do this? I was thinking

wgame.remove(visualObject)

But i'm not convinced because you need talk with the position for add objects to the board and with the game for remove them.

[npasserini]

Ok, this is just brain storming but

1) If we add objects using position.add(), what prevents us from having a position.remove()?

2) More complex... now we have mixins. Could we simply have a mixin with the default behaviour for visual objects:

• handle position
• handle image
• add/remove yourself from the board... maybe using some metaphore like "disappear" or "die"

On Wed, Dec 30, 2015 at 4:09 AM, Nahuel Palumbo notifications@github.com wrote:

How do you like do this? I was thinking

wgame.remove(visualObject)

But i'm not convinced because you need talk with the position for add objects to the board and with the game for remove them.

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

[PalumboN]

1) I didn't want the object must know the position for this. And we should verify that the object is in the position. But yes, we could.

2) Like! I agree.

[npasserini]

Two more thougths:

On Wed, Jan 6, 2016 at 3:13 AM, Nahuel Palumbo notifications@github.com wrote:

1) I didn't want the object must know the position for this. And we should verify that the object is in the position. But yes, we could.

We could allow both options, so if the object knows its position can use it, and otherwise you could just use the board/game/whatever.

2) Like! I agree.

I will slip from the topic, but I would like to think about a (modular) open class (and open object) system.

So instead of having the student write:

object pepita mixed with VisualObject { ... }

you could write

object pepita { ... } // no visual/game code

and it gets extended in another module (provided by the teacher or wollok itself):

import birds.pepita

extend object pepita mixed with VisualObject // whatever, we have to polish the syntax, but I hope you get the point.

The same mechanism could allow you to add/override methods to/from pepita (or any class/object).

[PalumboN]

import birds.pepita

extend object pepita mixed with VisualObject // whatever, we have to polish the syntax, but I hope you get the point.

Wooww this would be excellent! Very useful. And help us to respond the last Javi's comment here https://github.com/uqbar-project/wollok/issues/488

[javierfernandes]

So, this will be some kind of open-class or "extensions mechanism". It must be thought in the context of:

• a module system (we have freedom there to change the current imports, since they are not 100% implemented and are not currently "complete" -you cannot import content from other folder)
• being aware of type system restrictions / complexities

It should probably be an epic

[npasserini]

I think we should move this discussion to an independent issue.

On Thu, Jan 7, 2016 at 9:37 PM, javierfernandes notifications@github.com wrote:

So, this will be some kind of open-class or "extensions mechanism". It must be thought in the context of:

• a module system (we have freedom there to change the current imports, since they are not 100% implemented and are not currently "complete" -you cannot import content from other folder)
• being aware of type system restrictions / complexities

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

[PalumboN]

Ok! And for now, we can implement the other solution.