[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kopete-devel
Subject:    [Kopete-devel] Re: Status update
From:       Richard Smith <kde () metafoo ! co ! uk>
Date:       2004-01-24 20:03:07
Message-ID: 200401242003.07932.kde () metafoo ! co ! uk
[Download RAW message or body]

On Saturday 24 January 2004 6:12 pm, Martijn Klingens wrote:
> On Saturday 01 January 2000 22:55, Jason Keirstead wrote:
> > The problem with an APl like this ( yes it was considered, I know the
> > registerCommand is incredibly long ),
> > is it will make things INCREDIBLY terse in the objects adding commands.
> >
> > Consider, that the irc protocol adds almost 20 commands already, with
> > probably at least 15 more by next release.  Separating the API like
> > this  would increase the LOC count by at least five-fold in this area.
>
> Hmm, chicken and egg :)
>
> Generally reducing code size reduces clutter and results in more readable
> code.
>
> In this code however the more verbose version might actually be less
> cluttered and more readable instead.
>
> What might be an alternative approach is to let the register{Command,Alias}
> methods take the most basic parameters, instantiate a KopeteCommand object
> and RETURN a pointer to it.
>
> That way you can set additional properties after the register() call.
>
> I bet there are even more solutions to this (IMO too) long argument list.

I've seen the following being used for this sort of thing:

KopeteCommandSetup &register{Whatever}(...);

where the KopeteCommandSetup object has methods setMinArgs, setHelpText, and 
so on that all return (KopeteCommandSetup&)*this. Then the client says 
something like:

manager()->registerCommand("mycommand").setMinArgs(1).setMaxArgs(2)
  .setHelpText( tr("badger!") );

The KopeteCommandSetup object can actually be the KopeteCommand object if you 
like (depending on whether it makes sense to change the parameters after 
construction). Compare and contrast this approach to Qt's .args().

Looks like this pattern's not in the GoF, but I'm reasonably sure I saw it 
named somewhere. Ah well.

That's all.
Richard
_______________________________________________
Kopete-devel mailing list
Kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel
[prev in list] [next in list] [prev in thread] [next in thread]