Spike - Store secondary name for Features

[tamargrey]

• As a user, I wish Featuretools' Feature objects had the ability to store a secondary name for Features.

Given that multi-output features exist, this ability to store a second name would have to comply with there being multiple output features, and we'd have to decide if we would require secondary names to follow the naming convention of feature_name[0], feature_name[1], or if we would be okay with them not following that convention.

Code Example

I'm imagining that the secondary names would exist entirely separately from the primary name logic - since it doesn't get used anywhere in Featuretools itself, it should not be possible to accidentally access the secondary name from any of the existing logic.

feat = ft.Feature(...)
feat.set_secondary_name(...)

name = feat.get_name()
secondary_name = feat.get_secondary_name()

[thehomebrewnerd]

@tamargrey Instead of adding a specific secondary_name functionality, could we do this with a more flexible metadata dictionary instead? That might allow for additional user-specific information to be stored on the Feature without explicitly having to add a new property with getters and setters each time there is a need to store something else.

[tamargrey]

@thehomebrewnerd Yep, that definitely could be a possibility. Might just be worth examining why we've decided to add attributes to Woodwork instead of adding to the metadata (for things like origin or description) when they were needed by downstream users like EvalML or Featuretools and how exactly its metadata gets used (secondary, last time indexes in Featuretools for example) in order to decide which one better fits this use case