compareFn in map and map-keys? about es5-ext

[medikoo]

Hi Tomek! :)

Keys order on object is not guaranteed by specification, and you should never rely on it.
So even if you try to assign properties in specific order, it's not good idea to assume that reiteration will work in same order.

If I didn't get your reasoning, please explain further.

I'll close it for now, but let's keep discussion here.

[bsodzik]

Hello Mariusz :)

Of course I know that ordering of properties in object is not guaranteed by default, but quite common practice is to add order sub-property to each property of an object what can be then used for ordering. So the object could look like that:

var object = {
    propertyOne: { value: "One", order: 0 },
    propertyTwo: { value: "Two", order: 1 }
};

In my case I have several objects with order sub-property and I want to merge them into one object but preserving ordering of each of them. So my code looks like that:

extend(compoundObject, mapKeys(objectOne, function (name, value) {
    value.order = ++index;
    return name;
}, null, byOrder));

Of course in that case byOrder function will be ignored and sub-properties order for all properties from objectOne will be assigned with new value in non-deterministic order. The working code I use right now is:

forEach(objectOne, function (value, name) {
    value.order = ++index;
    compoundObject[name] = value;
}, null, byOrder);

Maybe the difference is not big, but I think that sometimes first approach with extend and mapKeys would be preferred over forEach. What do you think?

Kind regards,
Tomasz

[medikoo]

Tomek, thanks, still I have trouble understanding the example.. Is this a case, where there are holes in order properties e.g. it's 1,3,5,6 and you want to fix it so it's 1,2,3,4?

As otherwise setting value.order = ++index doesn't make much sense, as instead you could do value.order = value.order but that also doesn't seem to make much sense :)

[bsodzik]

I placed only a fragment of code and that could make the example vague. I have more objects which I want to merge into single compoundObject and in each one properties are ordered from 1 to n. Because of that in compoundObject I need to increase order of properties taken from second and third object and so on. Otherwise I would have multiple properties (as many as number of objects to merge) with order 1 and 2 and so on. More explanatory example would be:

var index = 0;
extend(compoundObject, mapKeys(objectOne, function (name, value) {
    value.order = ++index;
    return name;
}, null, byOrder));
extend(compoundObject, mapKeys(objectTwo, function (name, value) {
    value.order = ++index;
    return name;
}, null, byOrder));
extend(compoundObject, mapKeys(objectThree, function (name, value) {
    value.order = ++index;
    return name;
}, null, byOrder));

I hope now my use case is clear. Of course the question whether extend and mapKeys is better than forEach is still open and I would be glad to know your opinion on that subject :)

[medikoo]

Ok, few more questions :)

Why mapKeys? In above snippet you just reuse same name, do you change property names in original code?

Other weird thing, is that by reassigning order, you're changing order not only for compoundObject but also for objectOne, objectTwo and objectThree properties, are they temporary objects that are discarded (no longer used) afterwards?

[bsodzik]

Yeah, probably I should place original code.. I will send it to you as I don't want to share it in the Internet.

Of course I change property names, otherwise I agree using mapKeys would be simply stupid :) I am also aware that I am changing original objects, but this is not a problem since in my code they are actually copies of original objects:

var objectOne = copy(originalObjectOne);

[medikoo]

@bsodzik now it's clear, it's my fault! :P I totally overdone that piece then. I hope my email makes that clear, just use forEach seems simpler and more readable.

[bsodzik]

@medikoo yes, now everything is clear for me as well. I have to agree with you that with forEach code looks more readable so I will forget about mapKeys in this particular case. Thank you very much for great support! :)