Re: [OF] Gold codes in communication pkg?

[Mike Miller]

On Wed, Jun 4, 2014 at 15:45:10 +0100, Carnë Draug wrote:
> On 4 June 2014 10:38, Juan Pablo Carbajal <address@hidden> wrote:
>> On Wed, Jun 4, 2014 at 11:28 AM, Carnë Draug <address@hidden> wrote:
>>> On 4 June 2014 10:05, Juan Pablo Carbajal <address@hidden> wrote:
>>>> Yes, I understand it would be better to just provide a classdef
>>>> object, but I can do it at the moment. Is it preferable not to have
>>>> any implementation?
>>>
>>> I really ought to replace the current inputParser in the general
>>> package with a Matlab compatible version in core. And they are not
>>> compatible so I won't recommend you that.
>>>
>>> Carnë
>>
>> Shall I understand then that and old style object is preferred?
>
> You don't really need inputParser to implement the same type of API.
> It's a nice helper function but it's not a requirement, and in some
> cases it's even easier to not use it.
>
> I'd say just implement whatever is more sensible to you. Either way,
> it will be targeted for deprecation one day for replacement with the
> Matlab compatible version (if we actually ever get to do it is a
> completely different story).

One of the things I'm trying to focus on with the communications and
signal packages is improved compatibility, reliability, and stable
APIs. If we add a function that we know will be deprecated someday in
a future version, I would want to provide a compatibility wrapper to
use the new classdef implementation at that time and keep the
non-compatible interface for some number of releases. If I'm still
maintaining this package in a year or two, this is additional
maintenance work to keep compatibility for some period of time. IMHO
this is the biggest burden of introducing a non-compatible interface
knowing that it's not the right long-term solution.

Other than that, I agree, whatever makes the most sense, if one is
closer to what the eventual interface will be so the backwards
compatibility effort will be minimized.

-- 
mike