[Openev-discuss] Re: commands

[Frank W. <war...@po...>]

Gillian Walter wrote:
> Hi Frank,
> 
> I've been looking at the commands infrastructure in preparation for
> creating some new commands, and there are a few features that might be
> useful that I don't see there.  I am not sure if this is a result of
> lack of resources to implement them, or if there is a reason why they
> shouldn't be implemented.  In particular,
> 
> 1) Is there a reason why you can't name arguments?  The current
> implementation requires that if you want to specify an optional
> argument, you also have to specify all preceding arguments (eg. view3d:
> if you want to specify hscale, you also have to specify the drape and
> mesh so it doesn't get confused).  Do you think it would be reasonable
> to allow keyword style arguments (eg. hscale=0.5)?  I don't think that
> would be too difficult, unless we are going to want some variables to be
> allowed to have = signs in them.  The default for no keywords specified
> would be the previous behaviour.  It might also be nice to allow the
> keywords to appear in different orders, but the code changes for that
> would be a bit more complicated.  Do you have any thoughts on this?

Gillian,

It would be desirable for named arguments to be assignable for commands.
That was part of the reason for the "name" value in the gvcommand.ArgDef.
It isn't clear how hard it would be to implement this.

> 2) In-place modification of arguments: Currently there doesn't seem to
> be a mechanism for the commands to modify arguments in place.  This
> would be useful for commands such as "conjugate imgarr", where you might
> want to replace the original with the results without the extra = step.
> I can think of a possible way to implement this by allowing the
> functions to return a list consisting of an integer representing
> success/failure as the first element (this is what is currently
> returned) and a dictionary of output variable name-value pairs to set in
> the command shell as the second element, passed into the shell using
> something along the lines of:
>                 gview.temp_args = return_val
>                 code.InteractiveConsole.push(self,'from gview import
> temp_args')
>                 for value in temp_args.keys():
> 
> code.InteractiveConsole.push(self,value+'=temp_args['+value+']')
>                 gview.temp_args = None
> 
> Is the current approach to write python functions for that sort of
> command?  I also noticed that currently all the argument types are
> either strings or numbers represented as strings (hscale) rather than
> variables. ie.
> 
> view3d /data/gwalter/dem.hdr /data/gwalter/dem.hdr 5
> 
> will work but
> 
> meshlod=5
> view3d /data/gwalter/dem.hdr /data/gwalter/dem.hdr meshlod
> 
> will not.  This would be needed before in-place modification could
> occur.

It was not really my intention that variables could be freely used
and evaluated for any command argument, but I can see that this
could be desirable.  I think whether given command arguments
are evaluated as an expression, as opposed to being treated as a
literal would depend on the argument type.  That is, you wouldn't
be able to do this for all command arguments, only those where it
seemed to make sense.

> To someone who knows python, this functionality is redundant, but to a
> newcomer who might prefer the other style it could be useful.  I'm not
> really sure where the dividing line between python and the commands
> infrastructure should be.  Is there any convention on this from
> CIETmap?  Do you have any ideas about this?

The current pretty simplistic command approach came out of the requirements
of CIET for CIETmap.  You will need to be careful about changes to the core
command architecture so you don't break stuff for CIETmap.  I am cc:ing the
discuss list so Paul will be aware of your plans, and so he can comment.

Best regards,

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, war...@po...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent