Sistema de módulos para linguagem OOP


8

Estou projetando uma linguagem de programação OO simples.

É estaticamente digitado, compilado e executado por uma VM - semelhante ao Java.

A diferença é que eu não quero ter uma ênfase tão forte no POO. O código em si se assemelhará principalmente ao C ++ (classes, funções e variáveis ​​permitidas no escopo do arquivo).

Uma das coisas que eu preciso ter é um sistema de módulos. Eu tenho o seguinte descoberto:

  1. Todo arquivo é um módulo (uma vez compilado) - como Python
  2. Os programadores devem importar um módulo com a importpalavra - chave, o que faz com que o compilador procure por módulos nos diretórios padrão e no diretório de arquivos (a VM também precisa fazer isso em tempo de execução)

E agora não tenho idéia de como devo introduzir o conceito de submódulos e hierarquia de módulos.

Uma opção, por exemplo, é depender da hierarquia de diretórios, de modo que import engine.graphics.rendererseria de esperar encontrar um diretório chamado "engine" no diretório de trabalho e dentro de um diretório chamado "graphics", com um módulo chamado "renderer".

Quais são as desvantagens desse projeto? Estou faltando alguma coisa?


1
Bem, não seria o primeiro. Rust e OCaml tratam implicitamente o código em um arquivo como parte de um módulo com o mesmo nome que o arquivo. Parece funcionar bem o suficiente lá.
KChaloux

7
E Haskell. Se você está fazendo POO de qualquer maneira, recomendamos que você considere o Scala "Módulos são objetos especiais". Você também pretende apoiar módulos de primeira classe? foo.barNesse caso, existe uma ambiguidade entre ser foo / bar.file ou algum módulo foocom o membro (também um módulo) bar. Tudo a considerar
Daniel Gratzer

Como você planeja lidar com o controle de versão? Muitos idiomas não existem, mas é possível que você não cometa esse erro logo de cara.
Donal Fellows

@DonalFellows Gostaria de elaborar? Como é a responsabilidade do idioma lidar com versões? Mas, enfim, pretendia apresentar @annotationspara incorporar essas informações.
Aber Kled

@AberKled: Eu não acho que o problema seja tanto o idioma ser responsável por "manipular versões", como garantir que, se Fred tiver uma versão do módulo X ao escrever um módulo Y que funcione com ele, e Joe tenha um versão diferente do X quando ele escreve o módulo Z que funciona com ele, então, na ausência de diferenças comportamentais não resolvíveis entre as diferentes versões do X, deve ser possível usar Y e Z juntos sem precisar recompilar.
Supercat

Respostas:


2

Veja a hierarquia / organização de pacotes / módulos do Python e, principalmente no aspecto histórico, as principais adições ao longo dos anos, principalmente as mais recentes. Provavelmente, não faz sentido inventar a roda.

Não sei até onde você quer ir com o seu idioma, por exemplo

  • Deseja que os módulos bytecode sejam lidos do zip?
  • Como você separa módulos / bibliotecas para diferentes versões de intérpretes?
  • Você planeja torná-lo sem graça com distros?
  • Não se esqueça da facilidade de distribuição da própria linguagem (pense em distutils / pypi - cada plataforma / linguagem tem a sua, nem sempre é boa)

Eu acho que Java pode ser outro exemplo interessante. Também é possível aprender coisas da maneira de Erlang (por exemplo, /programming/2968914/code-hot-swapping-in-erlang ).

Existem muitos problemas de design (alguns mencionados acima) se você planeja ver sua linguagem de programação mainstream um dia. Felizmente, existem ótimos exemplos por aí.

Algumas instruções de design do módulo de linguagem de programação / pacote / biblioteca devem abordar:

  • código intuitivo para escrever e usar o módulo
  • objetos de módulo / pacote no código
  • recursos de introspecção de módulo / pacote
  • encapsulamento de módulo / pacote (como ocultar detalhes desnecessários?)
  • uso de interfaces / arquivos de cabeçalho?
  • sistema de envio com granulação fina, que tanto os utilitários de distribuição de idioma quanto os de nível de sistema podem usar (evite "DLL hell")
  • locais de armazenamento para módulos compilados
  • sistema de configuração, que automatiza a compilação de módulos "puros" e módulos / dependências
  • local canônico de código compilado, testes, documentação, ativos em seu módulo

é difícil ler este post (parede de texto). Você se importaria de editá -lo em uma forma melhor?
Gnat #

1
" Existem muitos problemas de design se você planeja ver sua linguagem de programação mainstream um dia. " Mas eu ainda apreciar se você me contou sobre as questões ...
Aber Kled

1
@gnat Obrigado por apontar. Esperançosamente melhor agora.
Roman Susi

1
@AberKled Eu tentei adicionar alguns. Mas, como eu disse na resposta, dê uma olhada na história do desenvolvimento de uma linguagem mainstream, melhor se for orientada pela programação de comunidades, em vez de puristas / elitistas, para aprender lições dos erros antes de criar a sua. Obviamente, não esqueça as principais metas de design do seu idioma.
Roman Susi

2

Primeiro, vamos supor que você mapeie seu modelo de namespace para outro namespace, como o sistema de arquivos, conforme sugerido. Segundo, estou assumindo que os módulos podem importar outros módulos. Em outras palavras, engine.graphics.rendererpoderia muito bem conter uma linha como import circle.arc. Isso levanta duas questões:

  • Onde a VM procuraria circle.arc? De acordo com o mappimg do sistema de arquivos mencionado, deve haver um diretório como /etc/mylang/modules/circle/arc ( /etc/mylang/modulessendo a raiz da estrutura do seu módulo) .

  • Como uma aplicação faria referência circle.arc: por importing circle.arcou engine.graphics.render.circle.arc? O primeiro "estragaria" (se não arruinaria) a hierarquia, porque circle.arcé claramente um submódulo de engine.graphics.renderer, e o segundo implicaria que deveria haver um /etc/mylang/modules/engine/graphics/renderer/circle/arcno seu sistema de arquivos, colocando-o circle.arcem dois locais simultaneamente.

Dito isto, e se você decidir seguir a abordagem de namespace, o mapeamento para o sistema de arquivos parece muito restritivo para mim. Eu acho que os módulos podem residir em todos os tipos de lugares (até arquivos zip, como já mencionado, até URLs). A VM começaria pesquisando uma entrada em algum tipo de índice (talvez um arquivo de configuração) que mapeie o espaço de nome para os locais reais do módulo.


1
Você provavelmente está recebendo votos negativos porque realmente não está respondendo bem à pergunta específica do OP. Se o seu comentário não puder transmitir o que você quer dizer, provavelmente precisará ter uma conversa mais ampla com o OP offline. Nossa sala de bate-papo é um ótimo lugar para fazer isso.
maple_shaft

@ maple_shaft: Como assim? Não é a pergunta "Quais são as desvantagens de um design desse tipo?" Não estou deixando claro o suficiente que meus pontos são desvantagens em potencial para a arquitetura de módulos sugerida pelo OP? A razão pela qual eu nunca perguntei por que recebi voto negativo é que venho do StackOverflow, onde as pessoas fazem isso o tempo todo sem se preocupar em deixar um comentário sobre isso - o que é frustrante e, mais importante, não construtivo , mas estou acostumado a no entanto, e cansado de pedir uma explicação.
Geomagas 13/10

1
Você admite que não pretende responder à pergunta e está mais ou menos esclarecendo seus pensamentos sobre o exemplo que ele forneceu sobre o que fazer com o módulo Renderer. A pergunta é realmente mais abstrata do que isso e acho que precisa de uma resposta mais ampla. Eu estava fornecendo uma explicação para seu benefício, porque acho que você levanta bons pontos e quer bem, mas, na verdade, isso não trata das partes principais da questão.
Maple_shaft

Bem, se a primeira frase foi o problema, eu a removi, pois ela não concordava com o restante da resposta - o que significa que, embora a tenha iniciado como "pensamentos", acabou abordando a questão real. Quanto à questão ser mais abstrata, acho que não, pois é expressa de uma maneira muito específica. Se eu estiver errado, espero que o OP especifique o que ele implicou, mas não colocou em palavras. Eu sei que seu comentário foi feito para ajudar, ao contrário do comportamento do Downvoter Anonymous , e eu aprecio isso. Eu realmente
Geomagas 13/10
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.