When array and when object key?

[gregorius]

Hi There,

One of the nice things about assignment is that arrays and objects are automagically created, so if I do the following assignments, everything gets created:

The following happens:

My question is why is the last twelve interpreted as a keyname for an object and not as an array of twelve elements, as the keys before it are?

So key2.5.12 creates a key key2 that becomes an array of 5 with the fifth element being an object with a key '12' with a value of 'dd'. I would have expected key2 to be an array with the five elements with the fifth value being an array of 12 elements with the twelfth element being 'dd'.

From the examples, it seems that the rule is that the last value is always a key-name for an object.

My question is therefore: is this assumption correct and is it a desired feature or a bug?

If it's a bug, it probably won't be fixed because of backward compatibility ...

[{"id":"518f89ca72f43970","type":"inject","z":"0dfc0365d20e2613","name":"","props":[{"p":"key1.123","v":"dd","vt":"str"},{"p":"key2.5.12","v":"dd","vt":"str"},{"p":"key3.5.3.12","v":"dd","vt":"str"},{"p":"key4.5.3.1.12","v":"dd","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":876,"y":1628,"wires":[["7b6f6a4bc9e6e2ac"]]},{"id":"7b6f6a4bc9e6e2ac","type":"debug","z":"0dfc0365d20e2613","name":"debug 445","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":1177,"y":1495,"wires":[]}]

Cheers!

[TotallyInformation]

Feels like a bug to me.

[Buckskin]

Well I am confused because I cannot see how an array comes into being. I would have thought that all of these should be Objects. I am sure that someone will explain why that is not the case

[TotallyInformation]

Yes, normally, you would use brackets to create arrays - have you tried that? Dot notation would normally create objects.

[gregorius]

@Buckskin

I cannot see how an array comes into being. I

It has to do with JS dual object addressing:

> obj = { 1:2, 'a': 3 }
{ '1': 2, a: 3 }
> obj.a
3
> obj['a']
3
> obj.1
obj.1
 ^^

Uncaught SyntaxError: Unexpected number
> obj[1]
2
>

An object can be addressed using array syntax or dot-notation. So what happens when I do obj.key[1]? Is key an array or an object?

The number dot-notation, i.e, key.1.2.3 seems to be an Node-RED extension of that logic: if objects can be addressed using array notation, why can't arrays be addressed using object dot-notation? key here might be an array then.

[gregorius]

@TotallyInformation

would use brackets to create arrays

Same behaviour, makes no difference

Gives:

brackets and dots are interchangeable in NR - which is actually a good thing (unlike in NodeJS) since it provides consistency but leads to this confusion!

[gregorius]

@TotallyInformation

Feels like a bug to me.

I would say no - I'm sure @dceejay or @knolleary were just waiting for someone to come along and ask why this is so, it's been cunningly planned all along. (I'm thinking of a scene out of Blackadder!)

Having now come to terms with it, I actually find it an elegant solution and saves much time creating nested JSON objects using the Json field - if used correctly.

BTW I did point out that using strings as indices causes objects to be generated: key[1][2]["3"][4] becomes

[
    null,
    [
        null,
        null,
        {
            "3": [
                null,
                null,
                null,
                null,
                "snafu"
            ]
        }
    ]
]

EDIT: Oh no, the last '4' now is an array if the thing before it is an object .... what is going on....

[gregorius]

dot-four versus bracket-four at the end:

It's a cunning plan ....

[Buckskin]

Well you learn something new everyday. However, according to MDN [JavaScript syntax requires properties beginning with a digit to be accessed using bracket notation instead of dot notation] so technically msg.key1.123 is not valid.

I will stick to [numeric] is an Array, ["numeric"] is an Object and ."numeric" is an Object. I probably will not use .numeric so I do not confuse myself in 6 months time.

[gregorius]

@Buckskin

technically msg.key1.123 is not valid.

That's not quite right because what NR is doing is using the characters 1, 2 & 3 these are indistinguishable from the numbers 1, 2 & 3 but they are completely different.

UTF-8b (a little know amendment to the UTF-8 standards) creates completely new range, for the characters representing the numbers. There has been discussion to add extra numbers for the characters, so that there might well be the number A (and it's negative value lower case 'a') but that's still in the works.

The reason for these amendments is that gender-ification of the alphabet has been seen to be unnatural and therefore, room should be given for characters that wish to be numbers, and vice versa.

What will happen to the floating point numbers is anyones guess. Some suggest the point should finally be fixated but no one really knows where.

Binaries, as the name suggestions, are fully compliant with the standard, being able to be both one and zero at the same time.

Hexdecimal are considering renaming themselves to octadecimal.

So NodeRED is doing everything right although it should be using the number open bracket and not the character open bracket.

.... sorry I had to write that

It's of course all from ChatGPT so I can't be ensure about the amendment, it might also be UTF-8c.

[TotallyInformation]

@Buckskin

so technically msg.key1.123 is not valid.

I agree, this is something inside Node-RED, not standard. Node-RED has a function that allows more flexible access for things like gets and sets and I'm guessing that is what this feature uses.

However, I still think the original reported results constitute a bug in Node-RED because the results are inconsistent.