Skip to content

Refactoring with breaking changes for more consistent naming in API #35

@GoogleCodeExporter

Description

@GoogleCodeExporter
There are a handful of API naming breaking changes we should like to undertake 
for the upcoming Unquote version 2.0.0 release where we feel the benefit 
outweighs the cost, the first is the most significant
  1. Rename `Swensen.Unquote.Operators.source` and the extension method `Expr.ToSource()` to `Swensen.Unquote.Operators.decompile` and `Expr.Decompile()` respectively. We feel this will be a more consistent renaming among the `eval` and `reduce` operators and will not impact folks who are only using Unquote for its main intended purpose as a unit testing assertion library.
  2. Consolidate `Swensen.Unquote.ExprExt` and `Swensen.Unquote.TypeExt` into `Swensen.Unquote.Extensions`. Since these are all AutoOpen modules, if they the two being consolidated were only used in that fashion, then this will have no effect on users. And also this will have no effect on users only using Unquote for its unit testing features.
  3. Rename `Swensen.Unquote.Operators.Private` to `Swensen.Unquote.Operators.Internal` and mark it with the `System.Obsolete` so that it is hidden from Visual Studio IntelliSense (the EditorBrowsable attribute not being honored by F#, a recently filed bug: http://stackoverflow.com/questions/6527141/is-it-possible-to-mark-a-module-function-as-hidden-from-intellisense-discovery/6527933#6527933). This shouldn't effect any users as the module was never intended to be used publicly and is only public because due to references by other legitimately public inlined operators.  

Original issue reported on code.google.com by stephen....@gmail.com on 30 Jun 2011 at 3:21

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions