[jira] [Assigned] (DAFFODIL-2249) refactor DSOM types to enable sealed classes/traits so case statements provide better warnings

["Mike Beckerle (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DAFFODIL-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Beckerle reassigned DAFFODIL-2249:
---------------------------------------

    Assignee: Mike Beckerle

> refactor DSOM types to enable sealed classes/traits so case statements provide better warnings
> ----------------------------------------------------------------------------------------------
>
>                 Key: DAFFODIL-2249
>                 URL: https://issues.apache.org/jira/browse/DAFFODIL-2249
>             Project: Daffodil
>          Issue Type: Improvement
>          Components: Front End
>    Affects Versions: 2.5.0
>            Reporter: Mike Beckerle
>            Assignee: Mike Beckerle
>            Priority: Major
>             Fix For: 3.0.0
>
>
> There are quite a few places where scala match-case logic is used in the daffodil schema compiler. This is typical of compilers, in that they often have algorithms that operate over a number of types that benefit from keeping the whole algorithm in one class.
> The scala compiler will produce valuable warnings that improve maintainability of the code if the types involved in the case analysis are sealed - that is, if the scala compiler knows the complete set of possibilities. 
> The DSOM types can be refactored so that the primary traits/classes used in case statements are all in one file where they can all be sealed, enabling the scala compiler's checking.
> These classes/traits are large and rich, so their definitions do not all want to be centralized into that one file.
> Hence, each DSOM type that ultimately derives from SchemaComponent should be split into a "Primary" trait that lives in the existing file, and a part that lives in a new central file for the sealed traits/classes.  Using ElementBase as an example, the centralized file will have
> {code}
> sealed abstract class ElementBase(....) 
> extends Term(....)
> with ElementBasePrimaryMixin
> {code}
> And the existing ElementBase.scala file would have:
> {code}
> final trait ElementBasePrimaryMixin
> extends ... list of everything already in the extends of ElementBase....
> { self : ElementBase =>
>  .... all existing contents of ElementBase class
> }
> {code}
> This enables us to also cleanup the schema compiler in that we can insure the traits/classes defined in the centralized file are all properly named so that those are the only traits/classes one uses in case statements. I.e., use of traits/classes whose names end in "...Mixin" would be exclusively in the extends-with clauses of trait/class definitions, and not in case analysis. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)