Support ColumnAttribute on properties and not just fields

[kevmal]

It looks like it's been considered:

machinelearning/src/Microsoft.ML.Api/SchemaDefinition.cs

Lines 318 to 319 in ea07be8

	// REVIEW: This will have to be updated whenever we start
	// supporting properties and not just fields.

I just wanted to get the issue started as it's probably the best solution to #180.

[zeahmed]

It could be a good feature to support custom transformation on some feature while using CollectionDataSource e.g. applying log on some numeric column(s).

[isaacabraham]

Please can you also support not just properties but also non-default constructors? This is important to get a coherent F# story going.

[dsyme]

I searched for uses of "GetFields" and here's what I see:

Relevant:

• The primary use in SchemaDefinition.cs that is the immediate cause of the F# problem
• A secondary use related to cursor channels in SchemaDefinition.cs
• A possibly-relevant use in TextLoader

Not relevant:

• Uses in sweep and LightLGBM parameters
• Uses in command argument and EntryPointUtils.cs which are not relevant to this issue
• A bunch of uses in tests

[dsyme]

@eerhardt I've taken a look at what it might take to fix this, could you take a look and check the general direction of travel please?

Here's the prototype: https://github.com/dsyme/machinelearning/compare/fs1...dsyme:fs2?expand=1

I've submitted a WIP PR for this though it is not yet complete: #616

[eerhardt]

Taking a look now. /cc @Ivanidzo4ka as well, since he was investigating allowing properties too.

[Zruty0]

Now that #616 is in, I think this one should be closed.

I discovered one inconvenient side effect though: we are requiring both the getter and the setter to be present and public for the properties. It adds confusion to the cases like in #595 , where you can use properties to act like 'calculated columns', without a clear way to provide a setter.

I'll open a new issue for this.