Skip to content

Proposal for different handling of scitype conventions #17

@ablaom

Description

@ablaom

Currently the possibility of allowing for different scitype conventions is handled by dispatch on a Convention object C, returned by convention() whose value can be changed by the user:

scitype(X;    kw...) = scitype(X, convention();     kw...)

@OkonSamuel, who has been profiling key ScientificTypes performance, has pointed out to me that this is overkill: It allows for the possibility of changing one's convention at run time (for which it is very hard to imaging a use case) but at the cost of some type-instability related loss in performance. It is therefore suggested that a convention should just means a set of overloadings of scitype(X; kw...) (instead of scitype(X, MyConvention(); kw...)) and choosing a convention means choosing the package which does the overloading (which commits the user to the convention once the package is imported).

Apart from performance benefits, this would also simplify code.

Although this is a breaking change, as far as I know this would currently effect only ScientificTypes - the only convention-providing package I know of.

Still, I would like to flag this in case there are objections to moving forward or other suggestions.

cc @OkonSamuel @juliohm @tlienart

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions