> On Wednesday 27 February 2002 05:20 am, Nathanael Schärli wrote:
>
> > a) Whenever someone wants to use two mixins with the same
> selector x, the
> > browser shows this selector in a special category "-- conflicts --" and
> > defines it as "self error: 'Mixin conflict!'" per default. This
> means that
> > the programmer has to resolve the conflict himself.
> >
> > b) When two mixin define the same selector, they cannot be used
> in the same
> > class
>
> Given that one can add or change methods at any time, when would
> the mixin
> conflicts be detected? Would you require an analysis of the entire system
> every time a class or method changed?

A new conflict can only occur if we add a new method to a mixin. However,
since mixins are typically only used in a very limited number of classes,
the only thing we have to do is to check whether there is a conflict in one
of these classes. (Because every mixins knows which classes it is used in,
that's a matter of milliseconds). If there is a conflict in a class, we make
sure that the conflicting selector also appears in the "conflict category"
of this class. In addition, we should probably inform the user with a popup
message.
And as I said before, if mixins are designed and used in a proper way, I
don't think that there are going to be many conflicts anyway.

I'm just about to finish my first prototype implementation and then I'll be
able to see how well it works and what problems I am running into.

Nathanael

BTW: In my first implementation, I'm going to deal with conflicts as
described in a). I have described it in more detail in an earlier message of
the thread "Behaviors vs Modules"