Open classes? [Or any other extension mechanism]

[flbulgarelli]

How difficult it is to make wollok classes and objects open?

Rationale: open classes are a very simple but powerful to understand way of extending components, It has a big downside - it is difficult to understand the actual interface of the object, it is not an structured way like more complex mechanism like extensions methods or typeclasses - but that is a problem that is not likely to occur on an initial object oriented course.

Anyway, having a way of extending objects and classes is very helpful on an educative environment, since you can provide a librar of object stubs which solved more complex problems, enabling an iterative building process that actually "compiles".

For example, see @mmatos issue at https://github.com/mumuki/mumuki-atheneum/issues/463

@PalumboN also states there that open classes could improve Wollok Game experience. I can figure out why, but I would like to read that from his own words.

[PalumboN]

In Wollok-Game, for rendering student's domain objects, we have many features that Its code would be nice to be in these objects. But sometimes it introduces concepts that a beginner student doesn't know, so we can't request it to them. With an extension mechanism, the teacher could extends those objects and add the expected behavior.

In this issue you can find a simple example of this, and a discussion where @npasserini think in open classes / objects.

[flbulgarelli]

So it seems there is some degree of consensus about adding open classes. Are there any rejections? @matifreyre @asanzo @javierfernandes @npasserini ?

Which are the interpreter complexities involved?

[npasserini]

+1

I wander if we want open classes or something more "aop-like".

On Thu, Mar 10, 2016 at 12:06 PM, Franco Leonardo Bulgarelli < notifications@github.com> wrote:

So it seems there is some degree of consensus about adding open classes. Are there any rejections? @matifreyre https://github.com/matifreyre @asanzo https://github.com/asanzo @javierfernandes https://github.com/javierfernandes @npasserini https://github.com/npasserini ?

Which are the interpreter complexities involved?

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

[flbulgarelli]

I personally prefer open classes since they are simpler, and they do not require any extra concept to extend objects.

But, If you want to teach abut AOP using wollok, well.. you will need an AOP style too :stuck_out_tongue:

Perhaps we can have both, can't we?

[javierfernandes]

I don't have anything against it. Just that the design should be consider a static type system.

I don't have a preferred mechanism or implementation. The underlying main motivation is to compose behavior. But i feel like diffenrent languages have different approaches. That just seems like mechanisms. I would really love to have one with a better semantic. Relating to an underlying concept like sepatation of concern aop and even sop and closely related to the module system. I mean if we want to do something serious it shpuld be a reseaech subject. Maybe a tip or research project by itself. El mar 10, 2016 12:24 PM, "Franco Leonardo Bulgarelli" < notifications@github.com> escribió:

I personally prefer open classes since they are simpler, and they do not require any extra concept to extend objects.

But, If you wan't to teach abut AOP using wollok, well.. you will need an AOP style too [image: :stuck_out_tongue:]

Perhaps we can have both, can't we?

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

[flbulgarelli]

Makes sense.

Perhaps we could just have a simple solution for the go - in order to quick solve the mumuki/wollok game issues - and think a better solution for the long term.

I am actually now thinking that Mumuki's and WollokGame's issues can be solved with just C# partial classes, which are a static - and also statically typed - way of defining behavior across multiple files.

So we don't even need in the short term dynamic open classes.

See https://msdn.microsoft.com/en-us/library/wa80x488.aspx

[javierfernandes]

Sounds good.

From looking at C# I think that we need to write a spec covering some things like:

• do we want to treat differently the "base class", from extensions ?
• is it necessary/desirable to declare the base class as "extensible" (partial in C#) in order to be able to extend it (I don't like much)
• what happens when you extend a class with abstract methods ?
• what happen if you declare a new superclass ?
• what if you add mixins ? What would be the order of composition ?

Just asking aloud

On Thu, Mar 10, 2016 at 2:15 PM, Franco Leonardo Bulgarelli < notifications@github.com> wrote:

Makes sense.

Perhaps we could just have a simple solution for the go - in order to quick solve the mumuki/wollok game issues - and think a better solution for the long term.

I am actually now thinking that Mumuki's and WollokGame's issues can be solved with just C# partial classes, which are a static - and also statically typed - way of defining behavior across multiple files.

So we don't even need in the short term dynamic open classes.

See https://msdn.microsoft.com/en-us/library/wa80x488.aspx

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

[flbulgarelli]

• do we want to treat differently the "base class", from extensions ?

I don't know. It is important that extensions look like normal classes, but I don't have any concern regarding the base class.

• is it necessary/desirable to declare the base class as "extensible" (partial in C#) in order to be able to extend it (I don't like much)

I don't like it that actually. But if you think it is necessary, I think it is not a big problem.

• what happens when you extend a class with abstract methods ?

I think there are two alternatives:

• consider it illegal, like it were duplicate definitions
• consider it legal, and the extended version overrides the base version

I think the first is simpler, and avoid accidentally overriding a base method.

But I am not particularly against the second alternative

• what happen if you declare a new superclass ?

I see here some alternatives:

• Consider it illegal
• Consider it legal, but only if the parent of the base clase is Object
• Consider it legal, but only if they match the original base class
• Consider it legal, and the extended class parent overrides the base parent

I can't decide myself. @PalumboN ? @npasserini ?

• what if you add mixins ? What would be the order of composition ?

We could

• Consider it illegal
• Consider it legal, and the new mixins have higher priority than the base ones. Duplicates are ignored

Here I think the second alternative is more powerful

Just asking aloud

[PalumboN]

My answers:

• do we want to treat differently the "base class", from extensions ?

I don't know too. But answering the next questions maybe we need it (especially for the last items).

• is it necessary/desirable to declare the base class as "extensible" (partial in C#) in order to be able to extend it (I don't like much)

I don't like too. If it's necessary I prefer to declare the extensions classes as "is an extension for" before the base class as "extensible". Because for the student (who will declare the base class) it would be transparent.

• what happens when you extend a class with abstract methods ?

The same as the other methods: you can't declare it again, so you can't override it in the same (whole) class. In other words, if the base class has abstract methods (abstract base class), all extensions are abstract, too.

• Now, can we declare abstract methods in the extensions?

For our propose, I think that it's not necessary.

• what happen if you declare a new superclass ?

Ufff, very difficult. I like the first three @flbulgarelli alternatives. Perhaps we can start considering it illegal and, if we need it, add that features after.

• what if you add mixins ? What would be the order of composition ?

I'm agree with @flbulgarelli choosing the second alternative. I think that Wollok-Game can take a big advantage of it.

[npasserini]

On Thu, Mar 10, 2016 at 11:35 PM, Franco Leonardo Bulgarelli < notifications@github.com> wrote:

• do we want to treat differently the "base class", from extensions ?

I don't know. It is important that extensions look like normal classes, but I don't have any concern regarding the base class.

I am not sure if we are talking about the same issue, but I consider very important that you have to be explicit about you wanting to "extend an existing class" vs. "declare a new class". Otherwise you could end defining a class twice without getting an error.

So I would like to write something like

extend object pepita uses GraphicObject {}

And expect the student to define pepita (he will get an error if he does not). (note that we talk also about extending named objects and not only classes)

• is it necessary/desirable to declare the base class as "extensible" (partial in C#) in order to be able to extend it (I don't like much)

I don't like it that actually. But if you think it is necessary, I think it is not a big problem.

I vouch for avoid changing anything in the base class.

• what happens when you extend a class with abstract methods ?

I think there are two alternatives:

• consider it illegal, like it were duplicate definitions
• consider it legal, and the extended version overrides the base version

Tough one. Maybe we should go for illegal.

I think the first is simpler, and avoid accidentally overriding a base method.

But I am not particularly against the second alternative

• what happen if you declare a new superclass ?

I see here some alternatives:

• Consider it illegal
• Consider it legal, but only if the parent of the base clase is Object
• Consider it legal, but only if they match the original base class
• Consider it legal, and the extended class parent overrides the base parent

First I would say that it is not easy to say which is "the base class" if you do not have a different syntax for class definition vs. class extension (the first question). I would go for "illegal" here. Changing the superclass is a very complex scenario. And you could work the same using mixins.

I can't decide myself. @PalumboN https://github.com/PalumboN ? @npasserini https://github.com/npasserini ?

• what if you add mixins ? What would be the order of composition ?

We could

• Consider it illegal
• Consider it legal, and the new mixins have higher priority than the base ones. Duplicates are ignored

Here I think the second alternative is more powerful

I think that having mixins is THE feature of the extending classes. Moreover we could have only mixins. The composition order should be that they come after the base class mixins... the difficult part is that I do not see how you could control the order between mixins added from multiple extensions.

Anyway, it is a rare case and we could just forbid it. Moreover, I think that we could forbid mixins conflicts all the way, and do not have any resolution order. I know that it is less powerfull than the current version, but if we want to introduce mixins in an introductory oop course, we should make them as simple as possible.

Just asking aloud

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

[javierfernandes]

On Fri, Mar 11, 2016 at 1:45 AM, Nico Passerini notifications@github.com wrote:

On Thu, Mar 10, 2016 at 11:35 PM, Franco Leonardo Bulgarelli < notifications@github.com> wrote:

• do we want to treat differently the "base class", from extensions ?

I don't know. It is important that extensions look like normal classes, but I don't have any concern regarding the base class.

I am not sure if we are talking about the same issue, but I consider very important that you have to be explicit about you wanting to "extend an existing class" vs. "declare a new class". Otherwise you could end defining a class twice without getting an error.

So I would like to write something like

extend object pepita uses GraphicObject {}

And expect the student to define pepita (he will get an error if he does not). (note that we talk also about extending named objects and not only classes)

I agree, I like to: 1) avoid declaring the base class as "can be extended", but on the other hand 2) be explicit on whenever you are trying to extend a class/object

• is it necessary/desirable to declare the base class as "extensible" (partial in C#) in order to be able to extend it (I don't like much)

I don't like it that actually. But if you think it is necessary, I think it is not a big problem.

I vouch for avoid changing anything in the base class.

• what happens when you extend a class with abstract methods ?

I think there are two alternatives:

• consider it illegal, like it were duplicate definitions
• consider it legal, and the extended version overrides the base version

Tough one. Maybe we should go for illegal.

I think the first is simpler, and avoid accidentally overriding a base method.

But I am not particularly against the second alternative

• what happen if you declare a new superclass ?

I see here some alternatives:

• Consider it illegal
• Consider it legal, but only if the parent of the base clase is Object
• Consider it legal, but only if they match the original base class
• Consider it legal, and the extended class parent overrides the base parent

First I would say that it is not easy to say which is "the base class" if you do not have a different syntax for class definition vs. class extension (the first question). I would go for "illegal" here. Changing the superclass is a very complex scenario. And you could work the same using mixins.

Ok so extensions will be basically either for 1) adding new behaviour 2) adding state 3) introducing new mixins

I can't decide myself. @PalumboN https://github.com/PalumboN ? @npasserini https://github.com/npasserini ?

• what if you add mixins ? What would be the order of composition ?

We could

• Consider it illegal
• Consider it legal, and the new mixins have higher priority than the base ones. Duplicates are ignored

Here I think the second alternative is more powerful

I think that having mixins is THE feature of the extending classes. Moreover we could have only mixins. The composition order should be that they come after the base class mixins... the difficult part is that I do not see how you could control the order between mixins added from multiple extensions.

Also there's question on the semantic of the extensions or "scope" of them. Extensions in xtend for example are locally to the client code and won't actually affect other modules or the extended classes. If understand correctly Smalltalk's and Ruby's way to extend classes are the opposite, they change the extended classes so their scope are globally. Then the most crazy but I suspect the most sound system is the one in Subject Oriented Programming, which is kind of a zen-oriented programming :P, the extension live tightly coupled to the extended instances (classes instances, or the object), but their visibility is bounded by the subjects (client code). This is specially useful for extension holding state. So whenever a module instantiate the base class it also trigger any initialization of the extensions, even if your module cannot see those extensions. Ok, I went too far.

I would see if I can read SOP and also newspeaks modules.

Anyway, it is a rare case and we could just forbid it. Moreover, I think that we could forbid mixins conflicts all the way, and do not have any resolution order. I know that it is less powerfull than the current version, but if we want to introduce mixins in an introductory oop course, we should make them as simple as possible.

I don't really like cutting the mixins implementation. I mean, we are now talking about open classes, which won't be used by the students but by wollok-game, and mumuki. So this means that the language is starting to exceed the initial student. As long as those feature can be just ignored (meaning that they are not used at all) and they are not there bothering or confusing then, I think that's fine. In particular for this case we could introduce an optional static check so that if the hierarchy chains has a conflict it will raise an error. That can be used for students, and deactivated for the sdk, game, etc.

Just asking aloud

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

.

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

[javierfernandes]

( continued sidenote about mixins...

Oh, also our mixins don't support mixins inheritance neither from another mixin or from a class. I found that in Scala to be the most complex and confusing part of mixins. Then there's also one thing to learn: simple linearization.

Anyway probably this needs to be used in a class to gather real experience from students users which don't know mixins at all. I think that it could even be used this year in a subject that teaches mixins. It seems stable enough)

[flbulgarelli]

:+1: with semantics proposed by @javierfernandes

As long a one side of the declaration - the base declaration or the extended declarations - can declare behavior and the other does not need any custom annotation, it suits my needs!

[PalumboN]

Agree