Suggestion: Allow dynamic variable types in datum

[koenniem]

Context

I am making my own PrivacySchema and one of its purposes is that needs to encrypt GPS coordinates since these are highly identifying data.

Motivation

Such a locationAnonymizer (using the flutter_sodium library would look like this

  /// A [LocationDatum] anonymizer function.
  Datum locationAnonymizer(Datum datum) {
    assert(datum is LocationDatum);
    LocationDatum ld = datum as LocationDatum;
    return ld..longitude = Sodium.bin2hex(SealedBox.sealString(ld.longitude, pubkey));
  }

However, this does not work as ld..longitude is a double (they are coordinates after all) while the encrypted value is a string.

Attempted solutions

I've some up with several solutions so far:

• Adding an extra string variable to LocationDatum. However, this variable would then not be used in other functions so it's essentially pointless.
• Overriding the LocationDatum myself to change longitude from a double to a string (using toString()). However, methods cannot be override outside their library.
• Binarizing the encrypted string. As expected, this led to a double overflow.

Proposed solution

In the respective packages with the Datums, change types from double to dynamic (or to string altogether) to allow for exactly this behaviour. I'm not sure if there are any downside for this other than giving in to a more loose typed way of programming.

[bardram]

hm... will think about this - after all, I'm an old-school OOP programmer, so loosely type checking works against my basic instincts ;-)

I wonder what other problems this might create.... But will make an experiment.

[koenniem]

Yes, I understand your aversion of giving in to loose typing. I'm not a fan myself either (JavaScript pstsd).

So if you find this use case something worth taking into account, and there is no better solution, and there are no adverse effects, I'd say this is the way to go.

[bardram]

I will try to release this as part of version 0.11.0.

However, it has a consequence on the JSON serialization. For example, if double values are used, the json look like this:

{
  "id": "47bfabd0-40a4-11eb-bbbe-ef47445b6df8",
  "timestamp": "2020-12-17T20:13:08.746280Z",
  "latitude": 3.34224,
  "longitude": 12.23342,
  "altitude": 124.2134235
 }

But when "encrypting", resulting in a string, it looks like:

{
  "id": "47bfabd0-40a4-11eb-bbbe-ef47445b6df8",
  "timestamp": "2020-12-17T20:13:08.746280Z",
  "latitude": 3.34224,
  "longitude": 12.23342,
  "altitude": "encrypted value"
 }

So - whatever is used for reading the json need to be able to handle that the attributes can both be numerical and strings.

[koenniem]

For me that's okay. I'm working on an R package for reading in CARP data (still in a very early stage) and any type would work fine there (even mixed, sometimes double sometimes string).