Verdadeiro ou falso: tipos

Se considerarmos,

var a:String = new String(“string”);
var b:String = new String(“string”);
var c:String = “string”;
var d:String = “string”;
Então:

1) a == b ?

2) a === b?

3) c == a?

4) c === a?

5) c == d?

6) c === d?

Respostas (publicado em 03/02/08):

Começando pela diferença entre os operadores de igualdade.

O operador de igualdade estrita (===) é como o operador de igualdade, com uma diferença importante: o operador de igualdade estrita não executa a conversão de tipo. Se os dois operandos forem de tipos diferentes, o operador de igualdade estrita retornará false (MACROMEDIA, Guia de Referência do ActionScript Flash MX 2004, pag. 44).

A variável a, assim como a variável b são objetos do tipo String. Ao serem comparadas com operador estrito ou não, sempre retornarão false.

1) a == b // false
2) a === b // false

Isso porque a e b são objetos diferentes. Mesmo sendo instâncias da mesma classe e contendo atributos iguais, eles possuem identidade diferentes, são armazenados em lugares diferentes da memória, assim as variáveis a e b são referências a objetos String e contém o endereço de memória de cada um dos objetos criados. Dessa forma podemos concluir que, quando comparamos a e b, sempre será false, pois em seu conteúdo não constam valores literais, mas distintos endereços de memória.

Então, como comparar os seus conteúdos?

a.valueOf() === b.valueOf() ou a.valueOf() == b.valueOf()

Mais uma consulta ao help do flash e temos, valueOf - Método; retorna o valor primitivo do objeto especificado. Se o objeto não tiver um valor primitivo, o objeto é retornado.

Já as variáveis c e d são tipos primitivos e possuem em seu conteúdo um valor literal que lhes foi atribuído. Veja mais um trecho do Guia de Referência AS:

Os tipos de dados descrevem que tipos de informações um elemento do ActionScript ou variável pode conter. Existem dois tipos de dados internos no Flash: primitivo e referência. Os dados do tipo primitivo — String, Number e Boolean — têm um valor constante e, portanto, podem manter o valor real do elemento que representam. Os de referência— MovieClip e Object — têm valores que podem ser alterados e, portanto, contêm referências ao valor real do elemento.

Assim, considerando que c e d armazenam um conteúdo e não uma referência a uma posição de memória, podemos afirmar que:

5) c == d // true
6) c === d //true

Com base em tudo isso, podemos concluir também que:

4) c === a // false

Considerando que estamos comparando uma referência de memória com um tipo primitivo.

Já no caso:

3) c== a // true

É verdadeiro porque o operador de igualdade (==) analisa conteúdos e faz a conversão de tipo. Como o conteúdo é idêntico, o resultado é verdadeiro, independente de serem valores literais, variáveis ou referências. Então você me pergunta, porque a== b não é verdadeiro então? E a resposta é… Como o operador de igualdade considera que c == a e String(a) == b são verdadeiros?

Objetos: Instâncias e referências

Objetos são instâncias de classes, que determinam qual informação um objeto contém e como ele pode manipulá-la. É através de objetos que (praticamente) todo o processamento ocorre em aplicações desenvolvidas com linguagens de POO.

Manipulando objetos

Quando declara-se uma variável cujo tipo é o nome de uma classe, como em:

var nome:String;

não está se criando um objeto dessa classe, mas simplesmente uma referência para um objeto da classe String, a qual inicialmente não faz referência a nenhum objeto válido:

Quando um objeto dessa classe é criado, obtém-se uma referência válida, que é armazenada na variável. Por exemplo:

   Nome = new String(“Nova instância”);

Nome é uma variável que armazena uma referência para um objeto específico da classe String, cujo conteúdo é “Nova instância”:

A variável nome mantém apenas a referência para o objeto e não o objeto em si. Assim, uma atribuição como

   var Nome2:String = Nome;

não cria outro objeto, mas simplesmente uma outra referência para o mesmo objeto

Referência:
http://www.dca.fee.unicamp.br/cursos/PooJava/objetos/manipul.html
O link acima está com explicações e exemplo de codigos para Java.

 

o maldito do espaço .

Lá vamos nós… decompila o fla e ahn, o evento cadê? não funciona. verifica daqui, verifica dali, vai, volta, nada. chama o adriano, senta olha olha olha… nada tudo ok, listener ok, sintaxe ok, object ok, diabos o que seria? nome de evento errado, copia e cola, copia e cola, copia e cola… nada… vem o fernando, testa tuuuudo de novo, desde o início: agora vai! Não, não foi. nada. Verifica, denovo, mais uma vez, cada detalhe… ai céus, não é nada!

[ pausa para xingamentos, raivas, promessas de nunca mais usar o flash... ]

and theeen…
Fernando: “LUCIANA MARIA! e esse espaço?”

por deus, no final do nome correto de cada evento, antes de finalizar a string com aspas, tinha um espaço…
ai ai, quem sabe se na proxima vida eu não nascer astigmata hipermétrope (depois de uma longa consulta ao google para saber como poderia me denominar – obrigada dani), eu encontro os espaços sem problemas!

Cache de Classes no Flash

Para não cometer o erro, ou a falha de alterar uma classe e o flash pegar a classe do cache, pode ser associada as teclas atalho do Control > Delete ASO Files and Test Movie ao CTRL + Enter.

Para isso, o Control > Test Movie tem que ter outro atalho ou nenhum. Caso queiram associar um atalho, sugiro o CTRL+M, pois não tem nenhum comando do programa associado.

Alteração fantasma

Fazia umas duas horas que eu estava alterando uma classe, compilando o fla e a alteração não aparecia.
Comecei a testar colocando (“) no código, forçando um erro na classe. Compilava novamente o fla e dava erro. Ou seja, funciona o erro e não funciona a alteração. ãh?
Chamei a Dani!!!

Expliquei e ela me falou que não tinha como ser a classe correta. Enfim, não era mesmo.
Ok, achei a classe certa.
Alterei a classe e compilei. Nada! #$%@#$%@@#$@%#$

Mais uns 30 min e percebi que o fla também estava errado. O Fla 1 carregava o 2, por isso, não percebi o erro e compilava o 1 ao invés do 2, que deveria receber a alteração, mais necessitava de um simples CTRL+Enter.

Tsc .. tsc .. tsc!!

fmw.Debugger(“Olá mundo”); // Ops, faltou o …

E lá vem uma história de sintaxe.

Era uma vez um evento que não funcionava. Mexi aqui e ali… E não funcionava… Não funcionava… Até que pedi água: “Lú, olha esse listener. Eu esqueci alguma coisa. Acho q é coisa boba, mas não estou enxergando.”

E a Lú mudou aqui e ali e continuava não funcionando. O Fernando (nosso dicionário de ActionScript ambulante) se juntou e nada! Eu até que estava desconfiada do trace dentro do listener (era a única coisa que tinha lá), mas quem decora sintaxe é o Fernado, que a essas alturas já estava olhando o código junto… Eu pensei: se eles que decoram sintaxe não falaram nada do trace, se eu falar levo uma xícara na cabeça. Então continuamos olhando o evento. E dispara evento e escuta evento… E nada. Então o Fernando teve a brilhante idéia: “Cria um outro evento“. A Lu criou, o evento funcionou e eu criei coragem: “Acho q é o trace“. E não é que era ele mesmo. Não levei a xícara na cabeça, mas esse trace vai me acompanhar por um bom tempo. É só eles verem um tarce que lembram de mim… E olha, que trace não se usa pouco…

Tudo isso porque resolvi usar o tal do trace do framework de flash daqui da empresa, cuja sintaxe é fmw.Debugger.trace(mensagem) e eu coloquei apenas fmw.Debugger(mensagem)… O Flash bem que podia ter avisado né, mas o bendito não deu nenhum errinho… só não acontecia nada.

Lição do dia: Os erros podem estar nas coisas mais simples. Que mania de achar que tudo é complicado, rssss…

1ª falha

A gente não sabe criar usuários para esse blog sem ter que criar um outro blog.

Resultado:
5 usuários do blog, 5 blogs … grgrgr

Bom, esse espaço é reservado aos flashers (expert mode ou topeira mode) que de vez em quando, ou melhor, sempre cometem alguma mancada como por ex:
- editar uma classe de um arquivo e testar no outro;
- escrever (tracee(“Olá mundo”)) e esperar que o flash entenda isso;

Enfim, assim poderemos aprender muito com os nossos erros e mancadas.