{'fraction_non_alphanumeric': 0.020833333333333332, 'fraction_numerical': 0.0, 'mean_word_length': 5.348017621145375, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
User-changeable visibility: resolving unanticipated name clashes in traits

A trait is a unit of behaviour that can be composed with other traits and used by classes. Traits offer an alternative to multiple inheritance. Conflict resolution of traits, while flexible, does not completely handle accidental method name conflicts: if a trait with method m is composed with another trait defining a different method m then resolving the conflict may prove delicate or infeasible in cases where both versions of m are still needed. In this paper we present freezeable traits, which provide an expressive composition mechanism to support unanticipated method composition conflicts. Our solution introduces private trait methods and lets the class composer change method visibility at composition time (from public to private and vice versa). Moreover two class composers may use different composition policies for the same trait, something which is not possible in mainstream languages. This approach respects the two main design principles of traits: the class composer is empowered and traits can be flattened away. We present an implementation of freezable traits in Smalltalk. As a side-effect of this implementation we introduced private (early-bound and invisible) methods to Smalltalk by distinguishing object-sends from self-sends. Our implementation uses compile-time bytecode manipulation and, as such, introduces no run-time penalties.