Path: news.mathworks.com!not-for-mail
From: "Steven Lord" <slord@mathworks.com>
Newsgroups: comp.soft-sys.matlab
Subject: Re: #include in matlab?
Date: Wed, 3 Dec 2008 10:10:50 -0500
Organization: The MathWorks, Inc.
Lines: 105
Message-ID: <gh67hq$pn5$1@fred.mathworks.com>
References: <fjreq3$t02$1@fred.mathworks.com> <aa5dace9-d6cc-4879-a706-a1bb8ab15574@b1g2000pra.googlegroups.com> <gh4o75$id1$1@fred.mathworks.com>
Reply-To: "Steven Lord" <slord@mathworks.com>
NNTP-Posting-Host: lords.dhcp.mathworks.com
X-Trace: fred.mathworks.com 1228317050 26341 144.212.105.187 (3 Dec 2008 15:10:50 GMT)
X-Complaints-To: news@mathworks.com
NNTP-Posting-Date: Wed, 3 Dec 2008 15:10:50 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Xref: news.mathworks.com comp.soft-sys.matlab:504694



"Joaquim Luis" <jluis@--ualg--.pt> wrote in message 
news:gh4o75$id1$1@fred.mathworks.com...
> DanK <dkominsky@primephotonics.com> wrote in message 
> <aa5dace9-d6cc-4879-a706-
>> Gus,
>> One way to do it is to use a switchyard function at the start of your
>> mfile.  What I do is that I have a huge file which is called something
>> like: application_support.m.  The application_support function at the
>> top of the file takes the first input to the function and uses a
>> switch statement to compare it against all of the subfunctions, and
>> then passes all the other input arguments to the subfunction.   Here's
>> an example:
>>
>> function varargout=VL200s_support(Fcn,varargin)
>>
>> % VL200s_support - Support routines for VL200 & VL300 processing
>> % Switchyarded routine for many subroutines
>> % Syntax: varargout=VL200s_support(Fcn,varargin)
>> % Fcn - Description
>> % varargin - Description
>> % varargout - Description
>> %   Example
>> %  Line 1 of example
>> %
>> % Subfunctions: VL200_Gen_ProcOPTS, set_constants, filterinit,
>> prepareData,
>> % processData, calculateFirstPeak, calculateAllPeaks,
>> load_Cal_spectra,
>> % VL200_LoadFiles, applyFilter
>> %   See also: VL200_main
>>
>> %% Create a switchyard for the functions:
>> varargout=cell(1,nargout);
>> switch lower(Fcn)
>> case 'loadonevlfile'
>> [varargout{:}]=loadOneVLFile(varargin{:});
> ...
>
>> then I when I want to call the applyFilter routine I use the following
>> syntax:
>>
>> [powerSpectrum,spectrumFiltered,cleaned]=...
>> VL200s_support('applyFilter',spectrum,lpFilter,Const,cleaned);
>>
>
> Actually you can reduce the obove solution to (that's what I use)
>
> function  varargout = my_funs(fun,varargin)
> % Library of some functions
>
> if (nargout)
> [varargout{1:nargout}] = feval(fun, varargin{:});
> else
> feval(fun, varargin{:});
> end
>

Rather than having the switchyard in the "library function", I'd build a 
"function struct":


% begin my_funs.m
function S = my_funs

S.VL200s_support = @VL200s_support;
S.prepareData = @prepareData;
% etc.

function y = VL200s_support(input1, input2, etc)
...
% end my_funs.m


That way I only need to call my_funs once, to retrieve the struct; when I 
want to invoke one of the functions from the "function struct", I simply 
perform a struct reference and directly call the function via the function 
handle.


functionTable = my_funs;
supportOutput = functionTable.VL200s_support(in1, in2, in3);


I can even use dynamic field names, if you need or want to allow the user to 
select what function should be run.


z = functionTable.(selectedFunction)(...)


Another benefit of this is that if the functions whose handles you store in 
the "function struct" are in separate files, things like DEPFUN will 
recognize that my_funs depends on those separate files (because I'm creating 
a function handle to it) whereas if you pass in the name of the function, it 
may not.  This is the same type of issue as the missing callback problem 
described here:

http://www.mathworks.com/access/helpdesk/help/toolbox/compiler/bq6ae_n-1.html#bq6ae_n-6

-- 
Steve Lord
slord@mathworks.com