consider ignoring inherited properties in StrMap implementations about sanctuary-type-classes HOT 9 CLOSED

it would help developers by giving them a very clear idea of what a StrMap is, it is a very simple thing, a POJO that maps to whatever your as are

This is how we should describe string maps to people regardless of how we handle this edge case. My preference is to permit the rarely useful behaviour we've been discussing, but this doesn't mean we need to advertise it. Every example of a string map in the documentation is currently an object literal, and I don't see any reason for this to change.

The definition should be precise of course, but this could be followed by a less technical description:

A value of type StrMap a is an object whose type is 'Object' and whose enumerable properties are all members of type a. A string map is a plain JavaScript object, such as {foo: 1, bar: 2, baz: 3}, whose values are all members of some type (Number, in this case).

from sanctuary-type-classes.

This issue has just become clearer in my mind. These properties should undoubtedly hold:

• S.keys(S.concat(map, {})) = S.keys(map)
• S.keys(S.concat({}, map)) = S.keys(map)

It's not difficult to find a counterexample:

function Point() {}
Point.prototype.x = 0;
Point.prototype.y = 0;

var map = new Point();

S.keys(map);
// => []

S.keys(S.concat(map, {}));
// => ['x', 'y']

So, either S.keys needs to be updated to include enumerable inherited properties or Z.concat and S.concat need to be updated to ignore enumerable inherited properties. I far prefer the latter.

At some point during the next few days I will open a pull request for this breaking change to Z.concat.

from sanctuary-type-classes.

I look forward to understanding your reasons for suggesting that all enumerable properties should be ignored

I'm assuming you meant "...suggesting that not all enumerable properties should be respected" 😄

I honestly don't have strong feelings on this issue. But I do think we should have a clear definition of what StrMap is. That is unless Sanctuary defines a StrMap type.

To my mind StrMap in JS is something akin to

var emptyMap = {};
var singletonMap = {'foo': 1};

// in the extreme
var strictEmptyMap = Object.create(null);

I don't understand the desire to have a StrMap with inherited properties. That sounds like an extensible record type to me.

from sanctuary-type-classes.

I don't understand the desire to have a StrMap with inherited properties. That sounds like an extensible record type to me.

👍

from sanctuary-type-classes.

I'm assuming you meant "...suggesting that not all enumerable properties should be respected"

Oops. That should have read all enumerable inherited properties should be ignored. I'll correct the sentence to avoid further confusion.

I do think we should have a clear definition of what StrMap is.

I agree. Here's my initial attempt:

A value of type StrMap a is an object whose type is 'Object' and whose enumerable properties are all members of type a.

I don't understand the desire to have a StrMap with inherited properties. That sounds like an extensible record type to me.

This matrix is useful for framing the discussion:

                     +-----------+-----------+
                     |           |           |
                     |    own    |   proto   |
                     |           |           |
+--------------------+-----------+-----------+
|                    |           |           |
|       enumerable   |    ???    |    ???    |
|                    |           |           |
+--------------------+-----------+-----------+
|                    |           |           |
|   non-enumerable   |    ???    |    ???    |
|                    |           |           |
+--------------------+-----------+-----------+

Currently string maps are comprised of properties in the top two quadrants.

I'm open to making a change, but I'd like to know:

• which of the four quadrants would be considered; and
• what is the motivation for the change.

Motivation is important. The current behaviour is not very useful but it is consistent, it can be described simply, and it is straightforward to implement (and to implement efficiently) as it matches the semantics of the language's for ... in operator.

from sanctuary-type-classes.

I guess the motivation for me would just to be very clear what a StrMap is, or maybe more importantly what a StrMap is not, eg Point from the other thread. I'm trying to think if I ever use something like that as a StrMap.. I don't think so, but even if I did that feels more ramda-ish than a sanctuary-ism.

I think javascript devs would be comfortable with "own enumerable properties"? (ie, still can be described simply).

Slightly less straightforward to implement, but we could probably have some internal helper functions to keep things consistent as needed.

from sanctuary-type-classes.

I'm trying to think if I ever use something like that as a StrMap.. I don't think so

If we don't think that anyone would ever attempt to take advantage of the current "feature" then it doesn't matter from an API perspective what we do with enumerable inherited properties.

If you were to write the DigitCounter code above would you want to see an exception thrown at run time because you had made a mistake? If so, why should we consider this a mistake? I don't see the harm. Something I've found to be a minor source of frustration when working with Haskell is that GHC sometimes rejects valid programs, forcing me to rephrase my thoughts in terms it deems acceptable.

from sanctuary-type-classes.

If we don't think that anyone would ever attempt to take advantage of the current "feature" then it doesn't matter from an API perspective what we do with enumerable inherited properties.

Agreed, this is kind of what I was trying to get at ie the motivation is just that it is maybe more correct rather than it helping me type check my programs: it would help developers by giving them a very clear idea of what a StrMap is, it is a very simple thing, a POJO that maps to whatever your as are. Maybe this is not worth it, but I just really like what @gabejohnson wrote above haha

If you were to write the DigitCounter code above would you want to see an exception thrown at run time because you had made a mistake? If so, why should we consider this a mistake? I don't see the harm. Something I've found to be a minor source of frustration when working with Haskell is that GHC sometimes rejects valid programs, forcing me to rephrase my thoughts in terms it deems acceptable.

You are questioning for example if someone wanted to call S.keys on their DigitCounter, this new stricter definition would throw? Could definitely be annoying. Some thoughts.. there might be other very easy ways for devs to achieve what they want without using a StrMap function, eg Object.keys or 'foo' in x. An Indexable type class for functions like S.keys that could accept more things.

from sanctuary-type-classes.

I can dig it 👍

from sanctuary-type-classes.