For greater Matlab compatibility, it'd be useful if inputParser offered either or both methods createCopy() [deprecated] and copy():
http://148.204.81.206/matlab/ref/inputparser.createcopy.html
https://www.mathworks.com/help/matlab/ref/inputparserclass.html
https://lostcontact.mit.edu/afs/cs.stanford.edu/package/matlabr2012b/matlab/r2012b/help/matlab/ref/inputparser.createcopy.html

For anyone coming here, because the guirelease branch was merged with default, the inputParser class was actually released with Octave 4.0.0.

A matlab compatible version of inputParser has been added to Octave core with cset ff820f92cbb5 now that classdef is mature enough to support it. It is planned to be part of the 4.2 release.
http://hg.savannah.gnu.org/hgweb/octave/rev/ff820f92cbb5

For those of you  like me  stuck with
Matlab/Octave crosscompatibility requirements:
<https://github.com/fgnievinski/inputParser2>
This is a wrapper for Octave's and Matlab's inputParser routines,
so that mcode can be ran unmodified in both environments. Code
originally written for Matlab need only append a "2" suffix to the
to the initial call to inputParser, i.e, p = inputParser2 (); it is
also recommended to add a call to dispose(p) just before the end of
the function using inputParser2(), to free up its memory resources.
Code originally written for Octave which wishes crosscompatiblity
with Matlab would need to be modified, adopting earlier the syntax
that will only become available in Octave after classdef is fully
implemented. The input/output syntax of the inputParser2 wrapper
is intended to adhere to Matlab's syntax and remain stable despite
future changes in the Octave implementation called internally.

You're right, the example was not working. I have fixed it with r12500. Thank you

there were more changes necessary to make the example run (with the original implementation); here's a plain diff file.
(file #30263)

In the example given in the function reference:
<http://octave.sourceforge.net/general/function/@inputParser/inputParser.html>
"@val_mat" and "@val_verb" need to be replaced with "val_mat" and "val_verb"; context:

We already have an almost compatible inputParser, why change it for another almost compatible version? I agree that with your changes, the almost compatible is bigger but let's consider that we apply them.
We apply your changes now and make a new release of the general package. We have to tell the current users of inputParser that we changed the API, and they must replace the current workaround with another one. Then, in a couple of months once Octave 4.2 is released with classdef, we fix inputParser so it's properly compatible. We have to tell all of them again to remove that workaround.
I guess that when we do it the second time, we can simply issue a warning that the the dispose method is deprecated, no big problem. But the worse part is that until the proper inputParser gets released in 4.2, we will have no way to find if dispose() is being called. We can document it now but what about the code that has already been written? I know that some Octave Forge functions already use.
I don't think it's worth the bother or risk. There's not many people crying out for inputParser, so I'd prefer to release a safe version once we get the possibility, i.e., for the version with classdef which has already been merged into the default branch.

please let me know if there remains any outstanding contentions. this brings an immediate benefit in terms of greater matlab compatibility in a concrete aspect that users have been inquiring about already.

this is easily taken care of with a dispose method for @inputParser:
as a small price to play for greater matlab compatibility, this patch allows users to retain their calling code intact, except for a oneliner at the very end of their usage:
if is_octave (), p.dispose (); end

I'm not super sure about this. Is the data being removed when the object is removed?
It seems like you're keeping everything in memory. Because after doing parse() the data is kept in the object, you'll run out of memory very quickly if you're dealing with many large datasets.

okay, here's the svn diff.
it took some moving around, I tried and kept the file histories.
I'm sending a zip with the result files, just in case.
as for the code design, the original @inputParser became @_inputParse_, which is used internally, e.g.:
let me know if anything is unclear.
(file #30200, file #30201)

Jordi,
About your comment that Matlab users still run versions from
2009 or 2008: this is often not because they really prefer
old versions, but the cost and hassle of updating is not
worth it.
It is quite convenient that this is not such a problem with
Octave.

I should also add, if you're in a rush due to some deadline at work or something, you can always patch and build your own Octave version and distribute it to whoever you want as long as you abide by the terms of the GPL.

> I'm looking at a time frame of the order of weeks not months.
What's the big rush? We are trying to release quickly, but there's no need to go that quickly. After all, people are still routinely running Matlab versions from 2009 or 2008, so it's not like the language implementation is in a huge rush to change.
> won't we have a 3.8.X before 4.0?
At the rate things are going, probably. But minor releases are just bugfixing releases. New features don't get added there.

I'm looking at a time frame of the order of weeks not months.
won't we have a 3.8.X before 4.0?
and OctaveForge general, which inputParser is part of, isn't part of the Octave base system yet, so that means even earlier update for that package.
the patch is not ugly, you'll see. it leaves your original implementation mostly untouched and just adds a push/pull storage facility to keep the "class" state persistent.

3.8 is already out and the 4.0 is guirelease which is targeted to developing the GUI and other small fixes.
The current default branch will be 4.2 which already has classdef. One could argue that adding inputParser could fit in 4.0 because it couldn't possibly break what's already present but one version later we'd be fixing the hacks that were used to deal with the missing classdef.
I think it's better choice to just do it properly with classdef. Pick what's already written in the general package and make it work in core using classdef. It even has some tests already written so this will be a good thing to test development of classdef.

okay, will merge into <http://sourceforge.net/p/octave/code/HEAD/tree/trunk/octaveforge/main/general/>
my goal would be for this to be included in the next release rather than waiting for release of classdef.

I wanted to take a look to see how you managed to workaround the missing classdef. Any chance you could merge your workaround with the implementation in the general package?
Also, this would probably be added to default which already has classdef so there would be no need for tricky business to work around it.
The general package already deals with all the things, there was no missing methods, and even had an extra one (addSwitch) not present in Matlab. The only problem it had was that one needed to do
instead of the Matlab compatible

any chance of having this patch incorporated?

here's a version compatible with matlab's  it passes tests like:
p = inputParser();
p.addRequired("req",@isnumeric);
p.addParamValue ("line", "tree");
p.parse(10, "line","circle");
assert(p.Results, struct("req",10, "line","circle"));
the two tests are
test @inputParser/inputParser
test @_inputParser/_inputParser
sorry it's a zip file  I'm still getting used to mercurial...
(file #30044)

Not yet. The one in the general package is not 100% compatible and can only be when classdef is finished. Since that will happen for 4.2, I'm guessing it will be moved from the general package into Octave core then.

should this be closed?

There's one in the general package from OctaveForge.

warning: the `inputParser' function is not yet implemented in Octave
Please read `http://www.octave.org/missing.html' to learn how you can
contribute missing functionality.
