Hot answers tagged

31

The seminal paper on mixins is Gilad Bracha's PhD thesis The Programming Language Jigsaw: Mixins, Modularity and Multiple Inheritance. It has answers to all of your questions, like Why not make a language with mixin-only inheritance? Jigsaw is such a language, as is Newspeak, Bracha's current language However, to me it looks like traditional inheritance ...


17

Figuring out all subclasses of a class is called Class Hierarchy Analysis, and doing static CHA in a language with dynamic code loading is equivalent to solving the Halting Problem. Plus, one of the goals of Scala is separate compilation and deployment of independent modules, so the compiler simply cannot know whether or not a class is subclassed in another ...


13

It's fine if a trait depends on methods in the class into which it is embedded. But these dependencies should be explicit, by declaring an abstract function. PHP can then check that such a method actually exists. But traits should not override methods. That is rather confusing behaviour. Instead, give a different name to the methods in the trait. In this ...


10

The change to Either was made on April 24th, 2008 in commit c0b21797bde81861305dd68853add2d8bd46e484 "Changed isLeft and isRight to use less memory.": Changed isLeft and isRight to use less memory. Changed either from a sealed trait to a sealed abstract class to allow exhaustiveness checking. All changes per the discussion in #797. The ...


8

Although it's usually good practice to accept as abstract of arguments as possible, in Scala you generally want to avoid directly using any types with [Repr] parameters. They are mostly there for the convenience of the standard library implementors. That's especially true for StringLike, which is primarily intended to augment a Java String to be able to ...


7

Yes, it's a code smell. If a trait is used to make code more portable, then then this sort of thing makes it less portable. You shouldn't do it. Without having a more concrete example it looks like what you should be doing is putting that bar method in an abstract and extending that. That approach avoids the potential runtime bug where the trait is added to ...


6

Although the Drop trait's drop() method is declared with &mut self, it is not actually possible to call that method directly. Instead you would have to use std::mem::drop() which takes ownership of the object. This makes sense: once a value has been dropped it no longer exists in an initialized state. Accessing it afterwards would effectively be ...


6

Composition is usually preferable to inheritance, unless you need substitutability. Traits are one specific way to perform composition. Usually you use traits when you need horizontal reusability, but it's also reasonable to use them for modularity, to break up a class that can't be broken up for some reason. It's relatively rare that you can't just split ...


5

The best way I have found to do this is as follows: class This_Is_My_Class { use My_Trait; protected $prefix = ''; function __construct() { $this->prefix = 'not_empty'; } protected function get_prefix() { if ( empty($this->prefix) ) { throw new Exception("Prefix must be non empty."); } ...


4

If these traits are part of the type's interface, they should ideally be asserted close to the declaration of that type. A static_assert is the ideal way to do that, since compilation will fail (rather than just your tests). In general, tests are useful for checking certain properties of your program by example. They cannot typically show that a program is ...


4

I don't think that the use of iterators you propose is an abuse of iterators at all. It's perfectly acceptable for iterators to perform computation and for them to have significant amounts of state. Rust has a lot of built-in tools for handling and composing iterators, so this is probably the easiest thing for your users.


3

Are these acceptable as unit tests? No. These are not acceptable unit tests. Unit tests should check behaviour rather than implementation. The unit test you have is not checking any behaviour of MyClass. Suppose I am another developer with doesn't really care about your regular types in your software suite, and I for some reason want to remove the copy ...


3

It sounds as if registration is a state which only has meaning in the context of a repository. You have described two states, (registered with the repository, not registered with the repository). It sounds to me as if what you need is a car container (wrapper if you like). Think of it as a collection which can hold one car, in the same way that Option[Car]...


3

It can be done (at least for all classes known at compile time), it's just expensive. You'd completely destroy incremental compilation, because everything that contains a pattern match would effectively have to be recompiled every time any other file changed. And what are you buying? It's a code smell to write pattern matches that need to change ...


2

I feel like I'm missing something, but I would just make your CarRepository a Map[RegistrationNumber, PlainCar] or something similar. Usually with immutable objects, it's much easier to create this kind of association outside the original object. My second choice would be RegisteredCar extends PlainCar, but I think this creates unnecessary coupling and ...


2

PHP does not have concept of mixins, however it has traits which look like mix of traits and mixins from hack/scala: Can define properties. Can define constructors. Can define abstract methods. Does not support inheritance. Traits are not types. Are these definitions accurate for any OO language or just for the above mentioned ones ? I don't think that ...


1

I, too, have a preference for regular types and value semantics. But I don't encode preferences into unit tests. Unit tests exist to enforce the requirements. Very occasionally, the best way to do something could be precluded by one of these preferences, so it's important that unit tests don't appear to create unnecessary implementation constraints. ...


1

From what you've described, I'd have to agree that inheritance seems like a better approach. But that opinions is based on knowing virtually nothing about the code base. Traits essentially provide a way to do "multiple inheritance", and yes it can sometimes be useful. Say for example you have a child class already inheriting from a parent, but there is ...


1

You can create a trait for Observable methods, implement the trait for your particular InterestingThing. If you want Dude to be observable, you must also implement the trait for Dude. One thing that might work is to add InterestingThing as a struct member for Dude, or maybe you can simply contain a <T: Observable> item that you later instantiate with ...


1

I do not know the pattern name (but it's probably using the Reflection pattern, see below), but many Web frameworks natively implement what your are trying to do here. For example if you look at Ruby on Rails, ActiveRecord and Mongoid are the components used to represent a Database entity, and programmers usually implement their model like this : class ...


1

This sounds like combination of strategy and composite patterns. Individual validators are strategy pattern. Then, composite is used to invoke multiple strategies as single one.


1

Hopefully someone will provide a better answer at some point, but in the meantime--in case anyone else is dealing with the same issue--here's the workaround I referred to in the question. Given the same trait and SUT, the below test will pass. It creates a "partial mock" of the SUT, replacing only the trait method and leaving the rest intact to exercise and ...


1

Best way I think trait ProductTrait { final private function getTable() { if ( empty($this->table_product) ) { throw new \Exception('$table_product must be defined in '. __CLASS__); } return $this->table_product; } //From here, just use $this->getTable() instead of $this->table_product } If a ...


Only top voted, non community-wiki answers of a minimum length are eligible