> [comment:111 annakrat] and [comment:113 hcho] don't want the underscore
for 3D raster, so this changes "`raster` and (`raster_3d` and `raster3d`)"
just to "`raster` and `raster3d`". [comment:102 I] already said that I
prefer `raster3d` over `raster_3d`. In my opinion such a common option
name as one for 3D raster (common for me and name of one of the basic
types) should not have an underscore.
Can someone, anyone, explain what exactly is the problem with underscores?
Why are they bad, why shouldn't we use them, etc?
To my mind, any name that is made of more than one word should have some
kind of separator between the words. For GRASS option names, "some kind of
separator" equates to an underscore.
> More generally, this whole issue shows to me what happens in an
unorganised release process where we start to release betas without being
sure that we are in a stable enough state to do so and then begin such a
fundamental review such as this one very late into the process...
It's always the same. If something can be left until later, it is. Once we
reach the "last chance to comment" stage, all of the discussions which
should have happened over the last half-dozen years start.
This isn't specific to GRASS. The standard that eventually became C++11
spent most of its life being referred to as "C++0x" on the assumption that
it would be published by the end of 2009 at the latest.
It's something of a chicken-and-egg problem. You don't get adequate
feedback until many people start using it, and many people won't start
using it until it's perceived as stable.
Replying to [comment:121 glynn]:
> Can someone, anyone, explain what exactly is the problem with
underscores? Why are they bad, why shouldn't we use them, etc?
To be it looks ok to change the element name "rast3d" to "raster_3d". If I
am not wrong it solves all technical problems, too, including
abbreviations etc.
Replying to [comment:123 neteler]:
> To be it looks ok to change the element name "rast3d" to "raster_3d". If
I am not wrong it solves all technical problems, too, including
abbreviations etc.
Replying to [comment:124 neteler]:
> Replying to [comment:123 neteler]:
> > To be it looks ok to change the element name "rast3d" to "raster_3d".
If I am not wrong it solves all technical problems, too, including
abbreviations etc.
>
> Opinions? Let's come to a decision, thanks!
I think most devs are OK with the underscore version. Personally, I don't
like the underscore, but I don't have any powerful argument, so I will
accept it.
Replying to [comment:125 annakrat]:
> Replying to [comment:124 neteler]:
> > Replying to [comment:123 neteler]:
> > > To be it looks ok to change the element name "rast3d" to
"raster_3d". If I am not wrong it solves all technical problems, too,
including abbreviations etc.
> >
> > Opinions? Let's come to a decision, thanks!
>
> I think most devs are OK with the underscore version. Personally, I
don't like the underscore, but I don't have any powerful argument, so I
will accept it.
Agree. I don't like the underscore version, but I'm OK with raster_3d
because it's at least better than 3draster or 3d_raster. Also, we don't
have to rename any modules and the parser doesn't have to treat numbers as
a special character.
Replying to [comment:130 martinl]:
> Replying to [comment:129 martinl]:
>
> > I think that it would be useful to modify parser to understand also
`rast` (`rast3d is OK because '_' is treated as word separator).
>
> attachment:raster_3d.diff
I'm generally against adding special cases in the code. IMHO, if the user
types `rast`, s/he means `raster` not `raster_3d` and it shouldn't be
ambiguous. Currently, the parser would stop with a parameter ambiguous
error. I think it would be more useful to modify the parser such that it
takes the shortest unambiguous parameter with no further underscores.
For example,
* modules with parameters `raster_map=` and `raster_3d=`: `rast` and
`raster_` would be ambiguous.
* modules with parameters `raster=` and `raster_3d=`: `r` and `rast` would
match with `raster=` and `r3` and `rast3` with `raster_3d=`
* modules with parameters `raster_map=` and `raster_map_2=`: `rast`
ambiguous, `rmap` for `raster_map=` and `rmap2` for `raster_map_2=`
* modules with parameters `raster_map=` and `raster_map2=`: `rast`
ambiguous, `rmap` for `raster_map=` and `rmap2` for `raster_map2=`
> * modules with parameters `raster_map=` and `raster_map_2=`: `rast`
ambiguous, `rmap` for `raster_map=` and `rmap2` for `raster_map_2=`
>
> * modules with parameters `raster_map=` and `raster_map2=`: `rast`
ambiguous, `rmap` for `raster_map=` and `rmap2` for `raster_map2=`
>
> I'm not sure if I was clear enough here.
You're suggesting that the abbreviation must include some part of the last
word of the option name? Or that it must include the last character? I.e.
is rm= ambiguous?
The main problems I foresee with that are
* The last word (or an abbreviation of it) might match some earlier
portion of the option name, meaning that the user intended to specify
(part of) the last word but the characters were matched against an earlier
portion.
* It's possible for a string to match the last word of multiple options.
E.g. given options raster_map and raster_2_map, rmap would match both
equally.
Replying to [comment:133 glynn]:
> Replying to [comment:131 hcho]:
>
> > * modules with parameters `raster_map=` and `raster_map_2=`: `rast`
ambiguous, `rmap` for `raster_map=` and `rmap2` for `raster_map_2=`
> >
> > * modules with parameters `raster_map=` and `raster_map2=`: `rast`
ambiguous, `rmap` for `raster_map=` and `rmap2` for `raster_map2=`
> >
> > I'm not sure if I was clear enough here.
>
> You're suggesting that the abbreviation must include some part of the
last word of the option name? Or that it must include the last character?
I.e. is rm= ambiguous?
No, not the last word of the option name. You cannot skip any words
separated by an underscore. rm= is not ambiguous in this case because the
shortest option name that matches rm= is raster_map=. If one wants
raster_map2=, use rmap2=, not rm2= (no abbreviation inside a word).
>
> The main problems I foresee with that are
>
> * The last word (or an abbreviation of it) might match some earlier
portion of the option name, meaning that the user intended to specify
(part of) the last word but the characters were matched against an earlier
portion.
>
I'm not talking about skipping words and using the last word, so this is
not the case.
> * It's possible for a string to match the last word of multiple
options. E.g. given options raster_map and raster_2_map, rmap would match
both equally.
rmap= would match raster_map= "only" because you cannot skip 2.
Replying to [comment:136 hcho]:
> Replying to [comment:133 glynn]:
> > Replying to [comment:131 hcho]:
> >
> > > * modules with parameters `raster_map=` and `raster_map_2=`: `rast`
ambiguous, `rmap` for `raster_map=` and `rmap2` for `raster_map_2=`
> > >
> > > * modules with parameters `raster_map=` and `raster_map2=`: `rast`
ambiguous, `rmap` for `raster_map=` and `rmap2` for `raster_map2=`
> > >
> > > I'm not sure if I was clear enough here.
> >
> > You're suggesting that the abbreviation must include some part of the
last word of the option name? Or that it must include the last character?
I.e. is rm= ambiguous?
>
> No, not the last word of the option name. You cannot skip any words
separated by an underscore. rm= is not ambiguous in this case because the
shortest option name that matches rm= is raster_map=. If one wants
raster_map2=, use rmap2=, not rm2= (no abbreviation inside a word).
>
I mean the shortest option name with no more following underscores. 'r'
for raster, 'm' for map, and no more underscores after 'raster_map'.
If you have `raster_map_1=` and `raster_map_2=`, `rm=` would be ambiguous
because `raster_map` is still ambiguous. If you have `raster_map=` and
`raster_map_2=`, `rm=` expands to `raster_map=` and it's not ambiguous.
> >
> > The main problems I foresee with that are
> >
> > * The last word (or an abbreviation of it) might match some earlier
portion of the option name, meaning that the user intended to specify
(part of) the last word but the characters were matched against an earlier
portion.
> >
>
> I'm not talking about skipping words and using the last word, so this is
not the case.
>
> > * It's possible for a string to match the last word of multiple
options. E.g. given options raster_map and raster_2_map, rmap would match
both equally.
>
> rmap= would match raster_map= "only" because you cannot skip 2.
>
> Hope I'm clearer now.
Replying to [comment:135 martinl]:
> Replying to [comment:134 martinl]:
>
> > `raster_3d` introduced in r63584.
>
> If no objections I will backport modified element names including
`raster_3d` to relbr70.