I'm new to Fantom and appreciate its beautiful succinctness. However, I don't understand this design:

Since a field of a mixin can only be abstract, isn't it redundant to write abstract in the declaration?

Since a field of a mixin can only be abstract, isn't redundant to write abstract in the declaration?

The abstract keyword is implied on the class level definition - in fact it is an error to declare it.

On methods however you must explicitly mark a method as abstract, since mixins can indeed have concrete methods (unlike Java interfaces).

I suddenly remembered another small problem.The default protection is public ,Is this means that we waste a keyword.

The abstract keyword is implied on the class level definition - in fact it is an error to declare it.

So the introduction of mixins is incorrect. It puts abstract before the field.

On methods however you must explicitly mark a method as abstract, since mixins can indeed have concrete methods (unlike Java interfaces).

This seems redundant too: If the method is concrete, it has a definition; otherwise it doesn't. In other words, it can be inferred whether a method is concrete or abstract.

After reading the documentation of mixins, I am certain the tour entry should be revised. It is a syntax error to use the keyword abstract anywhere in a mixin.

So the introduction of mixins is incorrect. It puts abstract before the field.

I looked it over again and it looks correct. Abstract fields are essentially a getter/setter without storage. In a mixin, fields must be abstract.

I think you misunderstood. Making mixin abstract is illegal. Making mixin with abstract method is perfectly normal.

Let me be clear. We are talking about two things: syntax and semantics.

Semantically, mixins can declare

• abstract fields
• abstract methods
• concrete methods

Syntactically, in mixins

• fields are always abstract, therefore the keyword abstract is unnecessary;
• abstract methods don't have a body, so they can be differentiated from concrete methods, which have a body, therefore explicit declaration of abstract is also unnecessary.

That's why I said this is only a design issue (e.g., for easy compilation, reader recognition, etc.) and it is stated in the Mixin Modifiers section of docLang:

It is a compile time error to use the abstract or final modifier with a mixin.

Either docLang or docIntro has to be changed to make them consistent.

I think I see now what you were trying to say.

The documentation is referring only specifically to the modifiers at the type declaration level.

At the slot level you are correct that you could potentially infer the abstract for fields. But slots are declared exactly the same between classes and mixins with an explicit abstract modifier, which I think is makes it clear exactly what is happening when reading the code.

For consistency, it might be better to require the fields as abstract in mixins.

It would allow a future change where a mixin could have an actual field (no idea how that would work, but it would save duplication in the implemeting class.

Brian, thanks for the clarification. It is of course up to you the designers to decide whether to keep explicit declaration of inferred modifiers. I was influenced by Java's design of omitting abstract in interfaces, which is easier because all slots are abstract or constant. Another similar case is that in Fantom all slots of enum are implied final hence not declared.

To avoid confusion, maybe the documentation can be revised as

It is a compile time error to use the abstract or final modifier on a mixin.

or more plainly,

It is a compile time error to declare a maxin abstract or final.