Interessante assumir a OLP - página 12
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Entendo que é uma questão de hábito e conhecimento de sintaxe, mas acho muito difícil entrar no código, embora eu seja o autor do original.
Infelizmente, eu não posso usar MQL no estilo FP. Em resumo, a seguinte abordagem é explorada: há condições de oferta (PammSet) e há funções que convertem condições em resultados financeiros (AccountRecord). Ambos os tipos são invariantes e definidos na criação. A tarefa é gerar um conjunto de ofertas e comparar cada elemento deste conjunto com o resultado financeiro através da função de mapeamento (Set1, Set2, Set3). O elemento chave é a função SELECT aplicando uma função arbitrária como Func<in, out> a cada elemento da seqüência.
Jacques Fresco na PF e na OLP
E como é fundamentalmente diferente do uso de ponteiros para funções?
é, é que a sintaxe FP é mais conveniente.
tão mais conveniente que toda a arquitetura de código é baseada nela
por exemplo, você pode criar um bloco que receberá uma tarefa que será executada quando o mouse for clicado .... por exemplo, para a GUI.
e lá você pode agrupar as chamadas em uma lista e adicionar o trabalho a ser executado de forma bastante simples
exemplo
Button1.MouseClickAdd(() => (aqui está um link para nossa função no estilo Funk();))
neste caso, tal configuração, ou seja, a tarefa, pode ser adicionada pelo usuário, que usa o código de nossa barra de ferramentas para configurar suas ações nos botões....
Neste caso, a ligação da função será tirada do escopo, ou seja, uma classe pode ser acrescentada a qualquer coisa. Portanto, não estamos adicionando o resultado final da função, mas a função a ser executada (chamada) quando esta condição ocorrer.
E como este PF é fundamentalmente diferente do uso de indicadores de função?
FP é uma implementação de lambda-calculus, e a programação imperativa (que inclui OOP) é uma implementação da máquina Turing.
FP é uma implementação de lambda-calculus, e a programação imperativa (que inclui OOP) é uma implementação da máquina Turing.
Faz sentido)
Acho que estamos discutindo "moscas e costeletas".
Se FP é um ótimo substituto para OOP, mostre-me um exemplo de GUI implementado em FP, não o exemplo acima
Кнопка1.MouseClickAdd(()=>(тут ссылка на нашу функцию в стиле Funk();))mas um exemplo dos botões, caixas de seleção, barras de rolagem, etc. - tudo feito em FP.
imho, se a PF ajuda a simplificar a formalização e a resolução de problemas, para não criar dependência deC++ da execução do código linear (de cima para baixo) - tudo bem! mas discutindo que a PF é uma alternativa à OOP (que surgiu do estilo processual), imho outra comparação de quente e frio
Acho que estamos discutindo "moscas e costeletas".
Se FP é um ótimo substituto para OOP, mostre-me um exemplo de GUI implementado em FP, não o exemplo acima
mas um exemplo dos botões, caixas de seleção, barras de rolagem, etc. - tudo feito em FP.
imho, se a PF ajuda a simplificar a formalização e a resolução de problemas, para não criar dependência deC++ da execução do código linear (de cima para baixo) - tudo bem! mas para discutir que a PF é uma alternativa ao OOP (que surgiu de um estilo processual), imho outra comparação entre quente e suave.
Aqui exatamente um não impede o outro, mas o complementa.
E se você quiser, você também pode criar tudo em PF como no OOP com a estrutura de Tyke - embora seja uma idéia muito duvidosaAqui é onde um não interfere com o outro, mas o complementa.
é sobre isso que estou escrevendo
e o artigo do primeiro post do tópico, tenta comparar dois paradigmas de programação completamente diferentes, em termos de propósito
FP é uma implementação de lambda-calculus, e a programação imperativa (que inclui OOP) é uma implementação da máquina Turing.
Exaustivo! Eu não acrescentaria mais ))