Uploaded image for project: 'Daffodil'
  1. Daffodil
  2. DFDL-1456

Code Style - Maintainability and Correctness Issues

XMLWordPrintableJSON

    • Icon: Improvement Improvement
    • Resolution: Won't Fix
    • Icon: Normal Normal
    • 2.0.0
    • None
    • clean ups
    • None

      This issue is a placeholder for lots of small corrections to the code needed to improve consistency, maintainability, etc.

      In some cases the suggested changes here are just so the scala compiler can do a bit more type checking, find more usage problems etc. E.g., things that avoid use of object vs. null are generally of that sort.

      ------------

      MStack.OfMaybe[T] - Mistake here is that if you have one of these named 'm' then m.popMaybe returns a T, not a Maybe[T]. You get an object or null. Unfortunately, once you do this it's pretty hard to catch, because null has this type which is a subtype of all AnyRef classes. This use of object vs. null is a common efficiency approach. Even a Maybe[T] which is AnyVal is allocated if you store it in a generic collection. Hence a collection that uses object or null internally to represent presence or absence, but externally uses a Maybe[T] as representation is a better API.

      The fix for this is to create a new class MStack.Maybe[T] where pushMaybe takes a Maybe[T] and popMaybe returns a Maybe[T]. The old class can be deprecated, and once all occurrences hunted down and converted, then it can be deleted.

      ----------------------------------

              Unassigned Unassigned
              mbeckerle.dfdl Mike Beckerle
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: