Boo não é Python

[Rodolfo Carvalho]

Transfomei um comentário que faria aqui em um post:

http://blog.rodolfocarvalho.net/2011/05/boo-nao-e-python.html

Este é pra lembrar que "as aparências enganam"...

E uma singelo alô ao nosso amigo Jonatas (acertei a grafia?) que talvez tenha ficado meio perdido... Boo não é Python, não é Iron Python, e nem é Ruby :P

Boo é Boo -- 'Cê 'táva certo Juan...

[]'s

Rodolfo Carvalho

[Juan Lopes]

Maneiro o post.

Não sei exatamente como é definido no Boo, mas no Ruby, onde a sintaxe é parecida, você tem o seguinte:

STMT : STMT if EXPR

STMT : EXPR

EXPR : ARG

ARG : PRIMARY

PRIMARY : return [`(' [CALL_ARGS] `)']

De qualquer forma, a coisa que mais me faz gostar de boo é não escrever "__init__", e sim "constructor".

2011/5/26 Rodolfo Carvalho <rhcar...@gmail.com>

--
* Coding Dojo Rio *
dojo...@googlegroups.com
http://groups.google.com/group/dojo-rio
http://code.google.com/p/dojo-rio
http://dojorio.wordpress.com

--

Kind Regards,

juanplopes@twitter

juanplopes@github

[Thiago Belem]

boo = python * 0.75 + .net * 0.3 + ruby * 0.05

[Rodolfo Carvalho]

Valeu Juan!

Eu aproveitei para dar uma atualizada e acrescentar este trecho da gramatica de Ruby q vc mostrou, e a parte relevante da de Python:

return_stmt: 'return' [testlist]
testlist: test (',' test)* [',']
test: or_test ['if' or_test 'else' test] | lambdef

E nada de encontrar a de Boo... daqui a pouco vou olhar no repositório procurando no fonte, ou não... :P

[]'s

Rodolfo Carvalho

2011/5/26 Juan Lopes <m...@juanlopes.net>

[Flávio Amieiro]

Gostei da idéia de postar esse tipo de coisa no blog ao invés de
transformar em um e-mail que vai ficar só aqui na lista e que, mesmo
aqui, muita gente vai simplesmente ignorar por causa do tamanho.

2011/5/26 Rodolfo Carvalho <rhcar...@gmail.com>:

[Marcius Oliveira]

Interessante o post muito bom, estava dando uma olhada em boo em conjunto com a unity3D, sim é bem parecido com python e linguagens modernas, mas, nota-se claramente que uma coisa é uma coisa e outra coisa é a outra coisa mesmo!!!

=D

confusão resolvida graças ao post =D

[Claudio Berrondo]

__init__ é disparado pelo "=" em 

seu_obj = SuaClasse()       (ah! e tem o __new__ também, viu?)

assim como o __add__ é disparado pelo "+" em 

seu_obj + seu_outro_obj

ou o __getitem__ é disparado pelos [] em

seu_obj[uma_chave]

ou o __hash__ de certa forma da mesma forma pelo [] em

qq_dic[seu_obj]

ou o __getattr__ pelo "." em

seu_obj.qq_atributo

ou o __nonzero__ por qualquer teste booleano como em

if seu_obj:

ou o __repr__ para que o seu objeto se represente quando você simplesmente

seu_obj

ou o __str__ quando você quer

print seu_obj

ou o __call__ para os "()" ou tornar o seu objeto "chamável"

seu_obj()

...

consistente.

__whatever__ remete ao protocolo (Javeiros chamariam "interface") padrão para todo e qualquer objeto Python, builtin ou criado por você.

ou a todo operador (=,+,*...) ou operação com o seu objeto corresponde um protocolo que pode ser implementado ou sobrescrito. e serão sempre os __whatever__ ...

mais (ou tudo...) em:

http://docs.python.org/reference/datamodel.html#basic-customization

><>Cláudio Berrondo

ps: sim, a convenção é usada ortogonalmente em outros pontos além do protocolo dos objetos.

[Juan Lopes]

Equivalentes:

__init__ => constructor

__add__ => op_Add

__getitem__ => Em boo, os índices são aplicados em propriedades, não em objetos. Então basta declarar uma propriedade com parâmetros (como se fosse um método).
__nonzero__ => op_True

__repr__ => sem equivalente

__str__ => ToString

__call__ => sem equivalente

2011/5/27 Claudio Berrondo <claudio....@gmail.com>

[Juan Lopes]

ah, __hash__ => GetHashCode

2011/5/27 Juan Lopes <m...@juanlopes.net>

[Jonatas Emidio de Souza]

Salve Rodolfo!!!

 

Grafia correta!! poucos acertam.

 

Li o post e achei show de bola!

Deixei lá o meu comentario.

 

 

(Boo é Boo - O fato de eu utilizar e gostar de python me deixou bem bitolado).

 

 

--

* Coding Dojo Rio *
dojo...@googlegroups.com
http://groups.google.com/group/dojo-rio
http://code.google.com/p/dojo-rio
http://dojorio.wordpress.com

--
Jonatas Emidio de Souza

http://varandageek.blogspot.com/

[Rodolfo Carvalho]

2011/5/27 Jonatas Emidio de Souza <jonata...@gmail.com>

Salve Rodolfo!!!

 

Grafia correta!! poucos acertam.

Que bom que minha memória não falhou!


 

 

Li o post e achei show de bola!

Deixei lá o meu comentario.

Obrigado.

 

 

 

(Boo é Boo - O fato de eu utilizar e gostar de python me deixou bem bitolado).

Taí um ponto que temos em comum, também utilizo e gosto muito de Python :D
Mas acho que a segunda parte não se aplica muito, procuro abrir a mente para outras linguagens.
A bola da vez é o Racket :D
Além das muitas coisas que se aprende ao entender programação funcional e Lisp (não necessariamente interligados), o ambiente criado ao redor do Racket é fantástico, da mais alta qualidade.

Recomendo! http://racket-lang.org

 

[]'s

Rodolfo Carvalho

[Rodolfo Carvalho]

Pessoal,

Eu tinha mais um email longo como resposta, então botei em prática minha auto-promessa de postar mais no blog, para quem sabe exportar o conhecimento que fazemos circular aqui para outros cantos.

Fiz uma reflexão das consequências de termos "__init__" ou "contructor" nas nossas linguagens (imagine-se criando a sua própria daqui a um tempo...):


http://blog.rodolfocarvalho.net/2011/05/sobre-escolhas-no-projeto-de-linguagens.html



[]'s

Rodolfo Carvalho

2011/5/27 Juan Lopes <m...@juanlopes.net>

[Juan Lopes]

Entendo a importância dos protocolos defindos com os "__whatever__". Não nego. Só acho que deveria existir algum açucar sintático para o "__init__". De qualquer forma, os equivalentes em Boo no post acima são, na verdade, definidos pelo próprio .NET.

Em .NET, todo objeto tem pelo menos 4 métodos: Equals, GetHashCode, GetType e ToString. Eles são métodos usados pelo framework para diversas tarefas. Tirando isso, o resto é definido por operadores. O fato dos métodos se chamarem op_Add, op_Subtract, etc., é uma convenção do .NET e não das linguagens. Em C# existe açucar para isso.

operator +(Tipo a, Tipo b) { ... }

Quanto a protocolos próprios, ainda prefiro a elegância de interfaces para isso. Duck typing é mais uma ferramenta do que uma filosofia para quem é fã de tipagem estática.

2011/5/27 Rodolfo Carvalho <rhcar...@gmail.com>

[Rodolfo Carvalho]

2011/5/27 Juan Lopes <m...@juanlopes.net>

Entendo a importância dos protocolos defindos com os "__whatever__". Não nego. Só acho que deveria existir algum açucar sintático para o "__init__". De qualquer forma, os equivalentes em Boo no post acima são, na verdade, definidos pelo próprio .NET.

Em .NET, todo objeto tem pelo menos 4 métodos: Equals, GetHashCode, GetType e ToString. Eles são métodos usados pelo framework para diversas tarefas. Tirando isso, o resto é definido por operadores. O fato dos métodos se chamarem op_Add, op_Subtract, etc., é uma convenção do .NET e não das linguagens.

Faz sentido que fosse...
Por exemplo, em outra plataforma, Clojure é Lisp mas acaba herdando várias coisas de Java por conta de rodar na JVM e ser bastante integrado com a linguagem Java.



 

Em C# existe açucar para isso.

operator +(Tipo a, Tipo b) { ... }

Vemos aí mais uma das "escolhas"... o quão "diabética" é a linguagem :D


 

Quanto a protocolos próprios, ainda prefiro a elegância de interfaces para isso. Duck typing é mais uma ferramenta do que uma filosofia para quem é fã de tipagem estática.

"Falou e disse!"

[]'s

Rodolfo

[Claudio Berrondo]

é como você disse, em Python há um padrão visivelmente* (literalmente) bem definido ;-)

* é, basta olhar para o texto :D

nintendi o __getitem__ ... em Python ele faz parte do protocolo de conteineres dicionários like. ou, pra fazer o seu objeto se comportar como um dicionário... ou responder ao protocolo de dicts...

eu ainda acho que eu estou ganhando :D ... o protocolo parece ortogonal, completo e bem definido em Python, independente da aparência e custo da digitação dos __ __ ...

http://docs.python.org/reference/datamodel.html#special-method-names

[Juan Lopes]

No .NET, para fazer um objeto responder ao protocolo de dicionários, basta implementar IDictionary<TKey, TValue> (desculpe linkar a MS nessa lista :P).

2011/5/27 Claudio Berrondo <claudio....@gmail.com>

[Claudio Berrondo]

em Python todo e qualquer protocolo está disponível em todo e qualquer objeto (ou quase). basta implementar o comportamento...

(vamos ver até quando o pessoal aguenta esse "em isso aquilo, em aquilo isso", kkkkkk)

gosto por gosto, esse CaMelCaSe à là Delphi é horroroso... :P

[Rodolfo Carvalho]

Em muitos dos casos os "protocolos" (Python) estão associados a algum açúcar sintático.

__getitem__ per se não tem nada a ver com dicionários. Mais sim com nome[item] ~~mágica~~> nome.__getitem__(item)

A classe que você quiser usar com a sintaxe nome[item] nem precisa ser verdadeiramente um container, pois sua implementação de __getitem__ pode fazer qualquer coisa.

Veja:

In [1]: import math

In [2]: math.pi
Out[2]: 3.1415926535897931

In [3]: class Foo:
   ...:     def __getitem__(self, item):
   ...:         return math.pi
   ...: 

In [4]: foo = Foo()

In [5]: foo["Quanto vale pi?"]
Out[5]: 3.1415926535897931

In [6]: foo["Qual seu número favorito?"]
Out[6]: 3.1415926535897931

In [7]: foo.__getitem__(42)
Out[7]: 3.1415926535897931

2011/5/27 Claudio Berrondo <claudio....@gmail.com>