Mirror DSL 1.2

danieldestro wrote:Então o "invoke()" e o "set()" não poderiam ser abolidos?

Eu acho que um invoke e set que já recebem o campo/método como parâmetro são o ideal. No caso de construtor eu acho que seria mais simples ter um método "create" que já receberia os parâmetros do contrutor.

Debugger Membro desde: 17/09/2007 18:42:58 Mensagens: 52 Offline

danieldestro wrote:Então o "invoke()" e o "set()" não poderiam ser abolidos?

Um dos focos era deixar o código bem legível (por isso uma DSL). Portanto, abolindo os dois ficaria bem menos legivel.

Até!

Quase um pseudo-código... hehehehe... Só não vamos falar de mnemônicos... kkkkk

Repetindo a pergunta, onde está o código fonte?

E eu tinha pensado em algo assim:

Acho bem mais intuitivo e menos burocrático

Debugger Membro desde: 17/09/2007 18:42:58 Mensagens: 52 Offline

Mauricio Linhares wrote:Repetindo a pergunta, onde está o código fonte?

jonasabreu wrote:Olá Mauricio,

por um erro acabei esquecendo de colocar no site (vou corrigir isso o mais rápido possível).

O source está em http://svn.vidageek.net/mirror .

Até!

parabéns pelo projeto. a api de reflection ficou mais simples e em poucas linhas você já faz muita coisa.

o tal do invokeMethod é muito chato ter que verificar e tratar exceções e ficou bem mais interessante.
está lembrando algumas características do smalltalk. só não lembro agora o nome desta característica, vários métodos aninhados.

Entusiasta Java Membro desde: 22/04/2007 16:57:39 Mensagens: 15 Offline

A título de conhecimento, existe uma API com proposta se não idêntica, muito parecida, fest-reflect. Parabéns pela iniciativa.

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Mauricio Linhares wrote:Repetindo a pergunta, onde está o código fonte?

E eu tinha pensado em algo assim:

Object o = Mirror.on("some.Class").create( "A String" ); Mirror.on(o).invoke( "aMethod" ).with( 13); Mirror.on(o).get("color");

Acho bem mais intuitivo e menos burocrático

Deixe-me aproveitar o gancho e dar uma sugestão ao projeto. Que tal criar junto a documentação do site uma sugestão de como se criar um 'Wrapper' para o Mirror, possibilitando que cada projeto possa elaborar/customizar a gramática que será usada?

Ou seja, a Mirror continua como está (que está bem legal), e ensina para seus usuários um jeito fácil de criar sua própria sintaxe usando uma classe que encapsule o Mirror.

Não sei se seria fácil, mas acho que seria bem legal

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Outra sugestão,

não sei se na opinião de vocês isso se enquadraria no perfil do Projeto Mirror. Mas algo que tem sido dificil de encontrar por aí de forma simples é uma forma fácil de se fazer uma busca por classes que atendam algum determinado critério no classpath.

Por exemplo: imaginem que quero encontrar todas as classes que possuam uma annotation do tipo @Entity e configurá-lo no hibernate.

Como já disse, não sei se este tipo de recurso estaria no escopo do projeto de vocês. Mas fica aqui a sugestão

Caso gostarem da idéia, um ótimo ponto inicial para começar é estudar a seguinte classe do Spring: ClassPathScanningCandidateComponentProvider

Valeu!

Thiago Senna wrote:Ou seja, a Mirror continua como está (que está bem legal), e ensina para seus usuários um jeito fácil de criar sua própria sintaxe usando uma classe que encapsule o Mirror.

Ótima idéia. Gostei!
Talvez algo usando os Matchers do hamcrest (que o JMock usa), para criar alguma forma de customizar a DSL interna.

Thiago Senna wrote:Por exemplo: imaginem que quero encontrar todas as classes que possuam uma annotation do tipo @Entity e configurá-lo no hibernate.

Outra ótima idéia! Acho que esse seria mais simples. Bastaria integrar com algo como o http://scannotation.sourceforge.net/

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Eu não conhecia o Hamcrest e o Scannotation. Valeu pela dica, Kung.

Achei bem interessante o projeto, mas se entendi bem o conceito de DSL, como não existe schema definido para representação abstrata da linguagem, ela não pode ser considerada uma DSL, seria por enquanto apenas uma classe de utilidades.

boaglio wrote:
Achei bem interessante o projeto, mas se entendi bem o conceito de DSL, como não existe schema definido para representação abstrata da linguagem, ela não pode ser considerada uma DSL, seria por enquanto apenas uma classe de utilidades.

creio que nao. quando a dsl é interna, estamos limitados pela sintaxe da propria linguagem (que ja possui uma sintaxe formalizada), fazendo a interseccao dela com a API exposta.

repare que o exemplo do fowler, a time and money API, nao define schema nenhum, e "segue as linhas de uma DSL", nas proprias palavras do Fowler:
http://martinfowler.com/bliki/FluentInterface.html

Paulo Silveira wrote:

creio que nao. quando a dsl é interna, estamos limitados pela sintaxe da propria linguagem (que ja possui uma sintaxe formalizada), fazendo a interseccao dela com a API exposta.

repare que o exemplo do fowler, a time and money API, nao define schema nenhum, e "segue as linhas de uma DSL", nas proprias palavras do Fowler:
http://martinfowler.com/bliki/FluentInterface.html

Legal! Isto já responde o comentário/dúvida que deixei no post http://blog.caelum.com.br/2008/11/17/mirror-dsl-facilitando-o-uso-da-api-de-reflection/

Sucesso!

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 687 Offline

boaglio wrote:
Achei bem interessante o projeto, mas se entendi bem o conceito de DSL, como não existe schema definido para representação abstrata da linguagem, ela não pode ser considerada uma DSL, seria por enquanto apenas uma classe de utilidades.

Qual trecho do artigo afirma isso?

Notícias, artigos e o maior fórum brasileiro sobre Java