Boo não é Python

15 views
Skip to first unread message

Rodolfo Carvalho

unread,
May 26, 2011, 6:23:10 PM5/26/11
to dojo-rio
Transfomei um comentário que faria aqui em um post:


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

unread,
May 26, 2011, 6:48:16 PM5/26/11
to dojo...@googlegroups.com
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>

Thiago Belem

unread,
May 26, 2011, 7:03:30 PM5/26/11
to dojo...@googlegroups.com
boo = python * 0.75 + .net * 0.3 + ruby * 0.05

Rodolfo Carvalho

unread,
May 26, 2011, 7:27:41 PM5/26/11
to dojo...@googlegroups.com
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

unread,
May 26, 2011, 8:36:00 PM5/26/11
to dojo...@googlegroups.com
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

unread,
May 26, 2011, 10:06:08 PM5/26/11
to dojo...@googlegroups.com
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

unread,
May 27, 2011, 3:19:09 AM5/27/11
to dojo...@googlegroups.com
__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:

><>Cláudio Berrondo
ps: sim, a convenção é usada ortogonalmente em outros pontos além do protocolo dos objetos.

Juan Lopes

unread,
May 27, 2011, 8:09:53 AM5/27/11
to dojo...@googlegroups.com
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

unread,
May 27, 2011, 8:15:55 AM5/27/11
to dojo...@googlegroups.com
ah, __hash__ => GetHashCode

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

Jonatas Emidio de Souza

unread,
May 27, 2011, 8:46:13 AM5/27/11
to dojo...@googlegroups.com
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).
 


 
--



--
Jonatas Emidio de Souza

Rodolfo Carvalho

unread,
May 27, 2011, 9:32:17 AM5/27/11
to dojo...@googlegroups.com
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

unread,
May 27, 2011, 10:55:52 AM5/27/11
to dojo...@googlegroups.com
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

unread,
May 27, 2011, 11:13:34 AM5/27/11
to dojo...@googlegroups.com
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

unread,
May 27, 2011, 11:29:30 AM5/27/11
to dojo...@googlegroups.com
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

unread,
May 27, 2011, 2:18:50 PM5/27/11
to dojo...@googlegroups.com
é 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 __ __ ...

Juan Lopes

unread,
May 27, 2011, 2:26:30 PM5/27/11
to dojo...@googlegroups.com
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

unread,
May 27, 2011, 2:31:29 PM5/27/11
to dojo...@googlegroups.com
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

unread,
May 27, 2011, 3:26:54 PM5/27/11
to dojo...@googlegroups.com
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>
Reply all
Reply to author
Forward
0 new messages