WIP add constructors for base array wrappers

[rafaqz]

Some constructorof methods for Base and LinearAlgebra array wrappers, as discussed in #34.

Probably we shouldn't add a constructor for Tridiagonal because of the undef field - seems it would break Accessors.jl/Flatten.jl etc?

I'm not sure what to do about it long-term, possibly a PR to base using nothing instead of undef for du2? How many other structs have undef fields?

Closes #34

There are probably a bunch of other base objects that need constuctorof methods. Feel free to list more for me to add to this PR.

[codecov-io]

Codecov Report

Merging #36 (dce6a09) into master (60cfb38) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master       #36   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            1         2    +1     
  Lines           38        60   +22     
=========================================
+ Hits            38        60   +22     

Impacted Files	Coverage Δ
src/ConstructionBase.jl	100.00% <ø> (ø)
src/nonstandard.jl	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 60cfb38...dce6a09. Read the comment docs.

[jw3126]

I think we can have this. It is a bit tough since it forces us to decide more precisely whether we want constructorof(obj)(public_fields...) or constructorof(public_and_private_fields...).

I am not sure, what's the right decision there, but I am okay with merging this and we will see later how it plays out.
Alternatively, we could also include a propertyvalues function, which by default returns all the fields, and specify

constructorof(obj)(propertyvalues(obj)...) == obj

[rafaqz]

I was thinking about a propertyvalues method as well. Then we could override it for Tridiagonal and the few other objects that have undef fields. I cant think of another way to support Tridiagonal.

[jw3126]

Ok lets go this path. How about a slight tweak. Instead of propertyvalues we could return a NamedTuple:

@generated function properties(obj)
    fnames = fieldnames(obj)
    fvals = map(fnames) do fname
        Expr(:call, :getproperty, :obj, QuoteNode(fname))
    end
    fvals = Expr(:tuple, fvals...)
    :(NamedTuple{$fnames}($fvals))
end

struct S;a;b;end
s = S(1,2)
properties(s)
(a = 1, b = 2)

You can still splat it into a function call, like it was a tuple.

S(properties(s)...)
S(1,2)

But it has nicer symmetry with setproperties, is easier to read etc. For me turning a struct into a NamedTuple is a task that comes up every now and then.

[rafaqz]

That looks good to me. Maybe we can call it propertiesof to match constructorof. Or getproperties. Idk maybe just properties is fine too.

[jw3126]

getproperties sounds fine.

[rafaqz]

This is updated to use the changes in the getproperties PR, and can be merged once that is rebased into master.

[rafaqz]

This is ready to rebase.

[rafaqz]

Made some changes to the tests if you want to hit merge if you're happy with them. I guess we should do a minor version bump after that.