Just in case anyone wonders: a workaround is to make the uses list empty
#(), this will remove the traits from a class.

And if I would not use traits, I wouldn't have known that. I use them to
give objects a common protocol based on a few would-be template methods
that are "required" by the trait (as described in the paper). I don't like
to impose abstract superclasses if there is no common, mandatory state,
such as instance variables.

Often my trait methods are general defaults that implement the protocol
simply, but not efficiently. This allows the user classes to adopt the
protocol quickly, based on a few "primitives" (not real primitives, but the
template methods). More efficient implementations can replace the trait
methods later. But it gets you started.

For the same reason I provide traits if I want others to implement that
protocol in their objects. At the same time, the traits "document" that
protocol, like interfaces in statically typed languages. Abstract
superclasses fulfill the same requirements, but seem to dictate
inheritance. While you can also just copy their methods, the copies will be
out of date when these methods are changed in the abstract superclass.

Am Do., 28. März 2019 um 16:22 Uhr schrieb <patrick.rein at hpi.uni-potsdam.de
>:

> The test documents the (currently not working) workflow for removing a
> trait from a class by simply removing the "uses:" line from the class
> definition. To make this work, we would have to make the
> Class>>#subclass:instanceVariableNames:classVariableNames:poolDictionaries:category:
> method aware of traits. The method would have to reset the trait
> composition as
> Class>>#subclass:uses:instanceVariableNames:classVariableNames:poolDictionaries:category:
> currently does. Potentially, the change could also be embedded deeper in
> the class creation code to avoid that duplication and make the other class
> creation methods more robust.
>
> I am hesitant, as I am aware that traits have been prevented from being
> integrated more deeply so far. At the same time, the described missing
> workflow has already led users to struggle with using traits in the first
> place. So as they are part of the system I would rather improve their
> usability. Any other oppinions?
>
> Bests
> Patrick
>
> >Patrick Rein uploaded a new version of TraitsTests to project The Inbox:
> >http://source.squeak.org/inbox/TraitsTests-pre.19.mcz
> >
> >==================== Summary ====================
> >
> >Name: TraitsTests-pre.19
> >Author: pre
> >Time: 28 March 2019, 3:30:48.769796 pm
> >UUID: 2ed07595-23e5-5f41-92ef-17c27ad0a017
> >Ancestors: TraitsTests-ul.18
> >
> >Adds a test case for removing traits from a class by simply executing a
> class creation method without a trait composition. This does currently not
> yet work.
> >
> >=============== Diff against TraitsTests-ul.18 ===============
> >
> >Item was added:
> >+ ----- Method: TraitTest>>expectedFailures (in category 'failures') -----
> >+ expectedFailures
> >+
> >+      ^ #(testRemoveTraitBySimpleClassDefinition)!
> >
> >Item was added:
> >+ ----- Method: TraitTest>>testRemoveTraitBySimpleClassDefinition (in
> category 'testing') -----
> >+ testRemoveTraitBySimpleClassDefinition
> >+
> >+      | classAv1 classAv2 |
> >+      classAv1 := self createClassNamed: #TraitTestMethodClassA
> superclass: Object uses: T1.
> >+      classAv2 := self createClassNamed: #TraitTestMethodClassA
> superclass: Object.
> >+
> >+      self assert: classAv1 == classAv2.
> >+      self assert: classAv2 traits isEmpty.!
> >
> >Item was added:
> >+ ----- Method: TraitsTestCase>>createClassNamed:superclass: (in category
> 'utility') -----
> >+ createClassNamed: aSymbol superclass: aClass
> >+      | class |
> >+      class := aClass
> >+              subclass: aSymbol
> >+              instanceVariableNames: ''
> >+              classVariableNames: ''
> >+              poolDictionaries: ''
> >+              category: self categoryName.
> >+      self createdClassesAndTraits add: class.
> >+      ^class!
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190328/ef5a5650/attachment-0001.html>