Replying to [comment:100 martinl]:
> Does it make sense to you?
Not really. I'd much prefer a general solution, i.e. if an abbreviation
matches multiple options, and one of them is a prefix of all of the
others, the abbreviation should be deemed to unambiguously refer to the
prefix option.
So e.g. if a module has "raster" and "raster_3d" options, "r", "rast" and
"raster" would all be deemed to unambiguously refer to "raster", while any
abbreviation intended to refer to "raster_3d" would have to include the
"3" (e.g. "r3", "r3d", "rast3", "rast3d", ...) to ensure that it cannot
also match "raster".
Replying to [comment:99 huhabla]:
> Replying to [comment:96 martinl]:
> > Replying to [comment:95 helena]:
> > > > -1 for voxel, than we could rename 'raster' to 'pixel'
> > > >
> > > > I am still not sure we need to rename than all modules from `r3`
to `vo`...
> > >
> > > so is there also an agreement to rename all r3.* commands to vo.*
commands and changing all manuals accordingly? If yes, this will require
several weeks of focused testing and
> >
> > not at all, personally I don't like to stick with shortened element
names (rast, rast3d) just because it makes our life easier. Taking in
account a real world it seems to me that the reasonable is to rename `rast
-> raster` and `rast3d -> raster3d` and to modify the parser to understand
also shortened element names.
>
> This would be absolutely my favorite solution.
I like `raster` and `raster3d`.
For example, there will be no need to change `grass.script.raster3d`
(which would end up as `grass.script._3draster` in the other case). From
this point of view `raster_3d` is also not good because underscore should
not be in the name of a Python module if possible and moreover I don't
like `raster_3d` in general. Shortening possibilities are not as important
to me as name without underscore.
What about the module names? Are we changing that? Or is `raster3d` just
`rast3d` in module names?
> For example, there will be no need to change `grass.script.raster3d`
(which would end up as `grass.script._3draster` in the other case). From
this point of view `raster_3d` is also not good because underscore should
not be in the name of a Python module if possible and moreover I don't
like `raster_3d` in general. Shortening possibilities are not as important
to me as name without underscore.
I would agree with that.
@glynn: please could you review your opinion on already attached patch. I
understand that you prefer some generic solution. On the other hand we
need to decide somehow (to find a compromise) since we would like to see
GRASS7 released in reasonable time.
> So e.g. if a module has "raster" and "raster_3d" options, "r", "rast"
and "raster" would all be deemed to unambiguously refer to "raster", while
any abbreviation intended to refer to "raster_3d" would have to include
the "3" (e.g. "r3", "r3d", "rast3", "rast3d", ...) to ensure that it
cannot also match "raster".
I have prepared for testing a new patch based on your suggestion
attachment:raster_3d.diff
Then
{{{
g.list rast3d
}}}
will work. The patch contains modification of the parser to understand
`rast`
{{{
g.list rast
WARNING: Please update the usage of <g.list>: option <rast> has been
renamed to <raster>
...
}}}
> For example, there will be no need to change `grass.script.raster3d`
(which would end up as `grass.script._3draster` in the other case). From
this point of view `raster_3d` is also not good because underscore should
not be in the name of a Python module if possible and moreover I don't
like `raster_3d` in general. Shortening possibilities are not as important
to me as name without underscore.
>
> What about the module names? Are we changing that? Or is `raster3d` just
`rast3d` in module names?
Personally I would tend to rename just
* element name `raster_3d` (or `raster3d`)
* module options e.g. `d.legend raster_3d`
I would not touch names of the modules, some of them already use shorten
names, eg. `d.rast.leg`, so I would keep `rast3d`. Similarly I would not
touch python module names.
> @glynn: please could you review your opinion on already attached patch.
I understand that you prefer some generic solution. On the other hand we
need to decide somehow (to find a compromise) since we would like to see
GRASS7 released in reasonable time.
It's preferable to doing nothing (i.e. leaving modules using abbreviated
forms), and is compatible with the result obtained by relaxing the
ambiguity rules.
Should we do something similar for option names? E.g. g.region, g.rename,
g.copy have rast= and rast3d= options.
* element name `raster_3d` (or `raster3d`)
* module options e.g. `d.legend raster_3d`
> I would not touch names of the modules, some of them already use shorten
names, eg. `d.rast.leg`, so I would keep `rast3d`. Similarly I would not
touch python module names.
>
> Any opinion from other devs?
I don't really like the underscore, I would go with raster3d, I think we
can manage to type raster3d because 3D rasters are generally not used as
often as rasters.
I would keep the names of modules as they are now.
Replying to [comment:108 martinl]:
> Replying to [comment:102 wenzeslaus]:
>
> > For example, there will be no need to change `grass.script.raster3d`
(which would end up as `grass.script._3draster` in the other case). From
this point of view `raster_3d` is also not good because underscore should
not be in the name of a Python module if possible and moreover I don't
like `raster_3d` in general. Shortening possibilities are not as important
to me as name without underscore.
> >
> > What about the module names? Are we changing that? Or is `raster3d`
just `rast3d` in module names?
>
> Personally I would tend to rename just
>
> * element name `raster_3d` (or `raster3d`)
> * module options e.g. `d.legend raster_3d`
>
> I would not touch names of the modules, some of them already use shorten
names, eg. `d.rast.leg`, so I would keep `rast3d`. Similarly I would not
touch python module names.
>
> Any opinion from other devs?
Replying to [comment:111 annakrat]:
> Replying to [comment:108 martinl]:
>
> > Personally I would tend to rename just
>
> * element name `raster_3d` (or `raster3d`)
> * module options e.g. `d.legend raster_3d`
>
> > I would not touch names of the modules, some of them already use
shorten names, eg. `d.rast.leg`, so I would keep `rast3d`. Similarly I
would not touch python module names.
> >
> > Any opinion from other devs?
>
> I don't really like the underscore, I would go with raster3d, I think we
can manage to type raster3d because 3D rasters are generally not used as
often as rasters.
I agree. I don't like the underscore either. Maybe, the parser could treat
numbers just like the underscore so that we can shorten raster3d as r3.
>
> I would keep the names of modules as they are now.
Like Martin mentioned, I don't think we need to change module names if we
go for raster3d because other modules already use short names.
> > I don't really like the underscore, I would go with raster3d, I think
we can manage to type raster3d because 3D rasters are generally not used
as often as rasters.
>
> I agree. I don't like the underscore either. Maybe, the parser could
treat numbers just like the underscore so that we can shorten raster3d as
r3.
Having the parser treat numbers as separate words shouldn't be a problem.
OTOH, while I can understand why people might not want to use e.g.
"back_ground" (to allow abbreviation as "bg"), I really don't see the
problem with "raster_3d". To me, "raster" and "3d" are entirely separate
words.
Replying to [comment:115 neteler]:
> I see the problem of no consensus here. Do we need to fork GRASS at this
point or postpone the release forever? (irony flag on or off as you wish)
My understanding was that we have or we are very close to consensus. I the
last round, [comment:108 martinl] suggested "`raster` and (`raster_3d` or
`raster3d`)" for options and elements (when leaving module names as they
are). [comment:112 mlennert] agrees with not renaming module names (if I
understand correctly).
[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. But [comment:114 glynn] does not see
the point in not using underscore in case of `raster_3d`. So, this is the
only unclear part depending on how strong is Glynn's opinion.
[comment:113 hcho] suggests to allow shortening of options also where the
numbers are. [comment:114 glynn] says that's possible.
Replying to [comment:116 wenzeslaus]:
> Replying to [comment:115 neteler]:
> > I see the problem of no consensus here. Do we need to fork GRASS at
this point or postpone the release forever? (irony flag on or off as you
wish)
>
> My understanding was that we have or we are very close to consensus. I
the last round, [comment:108 martinl] suggested "`raster` and (`raster_3d`
or `raster3d`)" for options and elements (when leaving module names as
they are). [comment:112 mlennert] agrees with not renaming module names
(if I understand correctly).
>
> [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. But [comment:114 glynn] does not see
the point in not using underscore in case of `raster_3d`. So, this is the
only unclear part depending on how strong is Glynn's opinion.
Why only Glynn's ? For me that question goes both ways. I have to admit
that I don't understand the opposition to raster_3d. Is this only based on
aesthetics ? In terms of ease of programming and usability, I have the
feeling that raster_3d is superior as it allows you to use the current
parser behaviour to use abbreviations like r3 which raster3d doesn't.
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...
Replying to [comment:117 mlennert]:
> Replying to [comment:116 wenzeslaus]:
> > Replying to [comment:115 neteler]:
> > > I see the problem of no consensus here. Do we need to fork GRASS at
this point or postpone the release forever? (irony flag on or off as you
wish)
> >
> > My understanding was that we have or we are very close to consensus. I
the last round, [comment:108 martinl] suggested "`raster` and (`raster_3d`
or `raster3d`)" for options and elements (when leaving module names as
they are). [comment:112 mlennert] agrees with not renaming module names
(if I understand correctly).
> >
> > [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. But [comment:114 glynn]
does not see the point in not using underscore in case of `raster_3d`. So,
this is the only unclear part depending on how strong is Glynn's opinion.
>
> Why only Glynn's ? For me that question goes both ways. I have to admit
that I don't understand the opposition to raster_3d.
So, sorry for misquoting you.
> Is this only based on aesthetics ? In terms of ease of programming and
usability, I have the feeling that raster_3d is superior as it allows you
to use the current parser behaviour to use abbreviations like r3 which
raster3d doesn't.
As I said before, I don't care much about abbreviations. I even consider
them bad. They are bad for the source code and most of the scripting
because of readability (I think we have a consensus on that). And they are
bad for manuals and tutorials because they are harder for user to
translate to GUI or QGIS (GUI or processing). So then I don't see the
point in putting so much effort into the abbreviated options. And I also
think that we cannot unabbreviate everything, some options would be just
too long, too unpractical. Anyway, I can manage to write `raster_3d`
everywhere and I will hope that everybody will do the same for all GRASS
core code and addons. Perhaps it would be useful to have some
environmental variable to disable abbreviating which could be used for
testing (or to speed up the parsing).
Replying to [comment:117 mlennert]:
> More generally, this whole issue shows to me what happens in an
unorganised release process
Not really: Martin, me and some others worked for *years* on the
consolidation. Just others didn't care too much until now. Eg I went
through the 4000 parameters and flags multiple times. Just join the party
> 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...
Concerning the beta releases:
And I am very sure that without the beta releases the widespread testing
which actually happens (also is possible thanks to the packagers preparing
installers for the various OS'es and distros who need a tangible package)
hadn't been done.
I've been dealing with end of semester and traveling. Wow! A lot of words
spilled over a small suggestion to simplify parsing in code and in
commands. FWIW, the underscore makes it a *little* easier to parse and
potentially shorten (if that is desirable) the term for GRASS's unique
3D/voxel format. It also makes it a little easier to quickly differentiate
the 2D raster things (raster and raster.x) from the 3D raster things
(raster_3D and raster_3D.x). I don't find an underscore that much trouble
to type, except on my iPad where I can't run GRASS anyway.
That said, it's not a big deal to me either way. Since one is very
minimally more difficult to type than the other (1 character), I'd suggest
whichever form makes programming easier. Maybe a simple vote is needed to
move on. I'm delighted to go along with the majority so we release the
next beta
