Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Mixins (whether as traits or something else) cannot completely prevent fragile base class syndrome, nor can strictly using interfaces. The reason should be pretty clear: anything you can assume about your base class's workings you could also assume about an interface. It helps only because it stops and makes you think, and imposes a boilerplate penalty if your interface gets too large, both of which tend to restrict you to needed and valid operations.</p> <p>Where traits really get you out of trouble is where you <em>already anticipate</em> that there may be a problem; you can then parameterize your trait to do the appropriate thing, or mix in the trait you need that does the appropriate thing. For example, in the Scala collections library, the trait <code>IndexedSeqOptimized</code> is used to not just indicate but <em>also implement</em> various operations in a way that performs well when indexing is as fast as any other way to access elements of the collection. <code>ArrayBuffer</code>, which wraps an array and therefore has very fast indexed access (indeed, indexing is the only way into an array!) inherits from <code>IndexedSeqOptimized</code>. In contrast, <code>Vector</code> can be indexed reasonably fast, but it's faster to do a traversal without explicit indexing, so it does not. If <code>IndexedSeqOptimzed</code> was not a trait, you'd be out of luck, because <code>ArrayBuffer</code> is in the mutable hierarchy and <code>Vector</code> is in the immutable hierarchy, so couldn't make a common abstract superclass (at least not without making a complete mess of other inherited functionality).</p> <p>Thus, your fragile base class problems are not solved; if you change, say, <code>Traversable</code>'s implementation of an algorithm so that it has <code>O(n)</code> performance instead of <code>O(1)</code> (perhaps to save space), you obviously can't know if some child might use that repeatedly and generate <code>O(n^2)</code> performance which might be catastrophic. But if you <em>do</em> know, it makes the fix much easier: just mix in the right trait that has an <code>O(1)</code> implementation (and the child is free to do that whenever it becomes necessary). And it helps divorce concerns into conceptually coherent units.</p> <p>So, in summary, you can make anything fragile. Traits are a tool that, used wisely, can help you be robust, but they will not protect you from any and all follies.</p>
    singulars
    1. This table or related slice is empty.
    1. PODo mixins solve fragile base class issues?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USRex Kerr
    1. USRex Kerr
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PODo mixins solve fragile base class issues?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. CO"can completely" -> I think you meant "cannot". Also I still do not understand what is special about traits that makes them better, even partially (you say "it helps", and can "get you out of trouble"), than an abstract class at preventing fragile base class issues. Your arguments for `IndexedSeqOptimized` would apply just as well if it was an abstract class, no? The fact that it's a trait makes it more general and frees you from a rigid hierarchy (allowing you to mix it at different points of the type hierarchy), but how is that related to aleviating the fragile base class problem.
      singulars
      1. PO
      1. USRégis Jean-Gilles
    2. CO@RégisJean-Gilles - I have tried to clarify. The point is just that you can use traits wherever you need them to provide self-consistent functionality that can work around known implementation differences. Abstract classes can only be used once, so they don't really let you solve the problem (except by going completely orthogonal: "compose, don't inherit").
      singulars
      1. PO
      1. USRex Kerr
    3. COWell, OK, but the fact that traits are applicable in more situations than abstract classes does not affect the issues with fragile base class/base trait. If anything, the problems are just visible in **more** situations with traits. I still have the feeling that the more general applicability of traits is orthogonal to the fragile base class issues and the possible ways to mitigate them.
      singulars
      1. PO
      1. USRégis Jean-Gilles
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload