A primeira função em um arquivo m (ou seja, a função principal ) é invocada quando esse arquivo m é chamado. Não é necessário que a função principal tenha o mesmo nome que o arquivo m, mas para maior clareza, deve . Quando a função e o nome do arquivo diferem, o nome do arquivo deve ser usado para chamar a função principal.
Todas as funções subseqüentes no arquivo m, chamadas funções locais (ou "subfunções" na terminologia antiga), só podem ser chamadas pela função principal e outras funções locais nesse arquivo m. Funções em outros arquivos m não podem chamá-los. A partir do R2016b, você pode adicionar funções locais aos scripts , embora o comportamento do escopo ainda seja o mesmo (ou seja, elas só podem ser chamadas de dentro do script).
Além disso, você também pode declarar funções dentro de outras funções. Essas são chamadas funções aninhadas e podem ser chamadas apenas de dentro da função em que estão aninhadas. Eles também podem ter acesso a variáveis em funções nas quais estão aninhados, o que as torna bastante úteis, embora um pouco difíceis de trabalhar.
Mais comida para reflexão ...
Existem algumas maneiras de contornar o comportamento do escopo de função normal descrito acima, como passar identificadores de função como argumentos de saída, como mencionado nas respostas do SCFrench e Jonas (que, começando no R2013b, é facilitado pelolocalfunctions
função). No entanto, eu não sugeriria criar o hábito de recorrer a esses truques, pois provavelmente existem opções muito melhores para organizar suas funções e arquivos.
Por exemplo, digamos que você tem uma função principal A
em um arquivo-m A.m
, junto com funções locais D
, E
e F
. Agora, digamos que você tenha duas outras funções relacionadas B
e C
nos arquivos m B.m
e C.m
, respectivamente, que você também deseja chamar D
,E
e F
. Aqui estão algumas opções que você tem:
Coloque D
, E
e F
cada um em suas próprias m-arquivos separados, permitindo que qualquer outra função de chamá-los. A desvantagem é que o escopo dessas funções é grande e não está restrito a apenas A
, B
e C
, mas a vantagem é que este é bastante simples.
Criar um defineMyFunctions
m-file (como no exemplo Jonas') com D
, E
e F
como funções locais e uma função principal que simplesmente retorna funcionar identificadores para eles. Isso permite que você mantenha D
, E
e F
no mesmo arquivo, mas não faz nada em relação ao escopo dessas funções, pois qualquer função que pode chamar defineMyFunctions
pode invocá-las. Você também precisa se preocupar em passar as alças de função como argumentos para garantir que você as tenha onde precisar.
Copiar D
, E
e F
em B.m
e C.m
como funções locais. Isso limita o alcance de seu uso apenas A
, B
eC
, mas marcas atualização e manutenção do seu código de um pesadelo, porque você tem três cópias do mesmo código em lugares diferentes.
Use funções privadas ! Se você tem A
, B
e C
no mesmo diretório, você pode criar um subdiretório chamado private
e lugar D
, E
e F
lá, cada um como uma m-arquivo separado. Isso limita o seu âmbito de modo que só pode ser chamado por funções no diretório imediatamente acima (ou seja A
, B
, e C
) e mantém-los juntos no mesmo lugar (mas ainda diferentes m-files):
myDirectory/
A.m
B.m
C.m
private/
D.m
E.m
F.m
Tudo isso está um pouco fora do escopo da sua pergunta e provavelmente é mais detalhado do que você precisa, mas achei que seria bom abordar a preocupação mais geral de organizar todos os seus arquivos m. ;)
^
, @idigas