mbind dimnames[3] NULL

[pascal-sauer]

> a <- new.magpie(1:10)
> mbind(a, a)
A magpie object (package: magclass)
 @ .Data:  logi [1:20] NA NA NA NA NA NA ...
 $ dimnames:List of 3
  ..$ region.region1: chr [1:10] "GLO.1" "GLO.2" "GLO.3" "GLO.4" ...
  ..$ year          : NULL
  ..$ data          : NULL
> dim(mbind(a, a))
[1] 10  1  2
> length(dimnames(mbind(a, a))[3])
[1] 1

Having dim[3] be 2 here is weird if dimnames are still just NULL, and the length of dimnames is 1. In contrast, if there is a name set it looks like this:

> a <-  setNames(new.magpie(1:10), "a")
> mbind(a, a)
A magpie object (package: magclass)
 @ .Data:  logi [1:20] NA NA NA NA NA NA ...
 $ dimnames:List of 3
  ..$ region.region1: chr [1:10] "GLO.1" "GLO.2" "GLO.3" "GLO.4" ...
  ..$ year          : NULL
  ..$ data          : chr [1:2] "a" "a"

I think we should align how the two cases work. How to best do this though? Do we want dimnames[3] to be c("NULL", "NULL") or c("dummy", "dummy") or something else? What do you think @codeZeilen @tscheypidi ?

[tscheypidi]

The consistent behavior would be that magpie objects always have dimnames (and probably also unique dimnames...so something like "dummy", "dummy1" in this case), but I am a bit afraid of how much legacy code this would break which is why I so far did not dare to change it.

[pascal-sauer]

I would see this as two separate issues:

1. The NULL case, which is particularly broken because dim(x)[3] != length(dimnames(x)[3]).
2. The non-unique dimnames case.
   For 1, I would think that this hardly ever occurs (although after thinking about it a bit, I'm not so sure anymore...). For 2, yes, that probably happens a few times.

[pascal-sauer]

So what we would want is the following invariant: magclass objects always have a character vector with length = dim as dimnames (so never NULL or NA) AND they should be unique (if they are not unique use make.unique). Are we on the same page here?

[pascal-sauer]

Then the questions are

1. do we want to implement this, despite the transition struggles
2. how to get there.
   I think 1) yes, 2) let's start with a note whenever the invariant is broken, can turn that into a warning eventually, and gradually fix cases where this comes up?

[tscheypidi]

I think the first issue with the NULL is the more critical one and probably the more easy to fix. With the unique-aspect I expect that this will cause various problems when fixing. So, I would propose, that if we want to fix it that we solely focus on the first aspect. But even for that first case I am still worried that it will cause a lot of troubles. So I am not sure if we should try it.

[codeZeilen]

   I think 1) yes, 2) let's start with a note whenever the invariant is broken, can turn that into a warning eventually, and gradually fix cases where this comes up?

Maybe we could first introduce that note and gather the situations in which people use empty dimnames to understand why this occurs to figure out what they want to express with that and whether that can also be expressed using dummy?