search

JarrettBillingsley / Croc

Croc is an extensible extension language in the vein of Lua, which also wishes it were a standalone language. Also it's fun.
http://www.croc-lang.org
79 stars 12 forks source link

Deal with clashing class member names #97

Closed JarrettBillingsley closed 10 years ago

JarrettBillingsley commented 10 years ago

Both the previous class models (differential inheritance and the privacy model) made it possible to define class member names which were already defined in base classes. In the differential inheritance model, they were simply hidden; in the privacy model, they had a different "owner" and were therefore overwritten with a new value/owner.

In this newest iteration, it's still easy to do this, but the problem is that it makes it too easy to mess things up. If we drop base classes like (#96) and move towards a mixin-oriented class model (#84), it's possible/likely that multiple mixed-in classes will use the same names for class members, meaning that currently they will just stomp all over each others' stuff and break things.

What I'm thinking is that two things will have to happen:

  1. Attempting to add a member which already exists to a class will give an error, rather than simply overwriting it.
  2. There needs to be an override keyword which, when applied to class members, will use field-assign behavior rather than trying to add the member. In this way, the member will overwrite an existing member of the same name, but if there is no existing member of the same name, you get an error.

These two things would also apply to the behavior of any object.mixin function, including a mechanism to resolve name disputes (such as passing a table mapping from names of clashing fields to the class which should "win").

JarrettBillingsley commented 10 years ago

I just realized a wrinkle with this. Any object.mixin function would operate on the class after its members have been defined, meaning that the override behavior wouldn't work properly.