E se não houvesse null no java

GUJ Expert Membro desde: 13/11/2008 12:10:18 Mensagens: 3927 Online

peczenyj wrote:O que me motivou a fazer esta pergunta é o fato de Haskell não ter null, porém é uma linguagem funcional.

O esquema do haskell deve ser bem diferente dessas demais. O compilador ou interpretador deve mapear todos os ponteiros resolvendo as referencias nulas e apontando-as para algum tipo de dado não nulo. Difícil de imaginar como mesmo.

This message was edited 2 times. Last update was at 02/09/2010 18:29:54

utlizando esse exemplo, onde cidade está nula:

Como a tipagem é fixa, quando não é utilizada uma referencia de memória, não podemos retornar um tipo diferente do declarado como retornado pelo método, pois dessa forma geraria outra exception como "Type mismatch: cannot convert from NullObject to Cidade".

E se em vez disparar NullPointerException fosse adotado um NullObject, geraria algo do tipo "The method getEstado() is undefined".

Só de ver casos como esses da pra ter uma idéia quantos detalhesinhos poderiam complicar a vida do programador.

É que voce foi muito profundo Julio, foi la na heap

Acho que a pergunta foi, se nao existir na linguagem como existe hoje, como seria o tratamento, como tratariamos isto em nosso código.

Em Scala eu simplesmente nao consigo criar um ponteiro nulo, tipo:

Ou seja(ainda to começando com scala, posso por ventura falar alguma asneira

), teoricamente eu nunca terei um ponteiro apontando pra null.

GUJ Expert Membro desde: 13/11/2008 12:10:18 Mensagens: 3927 Online

fredferrao wrote:É que voce foi muito profundo Julio, foi la na heap

Acho que a pergunta foi, se nao existir na linguagem como existe hoje, como seria o tratamento, como tratariamos isto em nosso código.

Em Scala eu simplesmente nao consigo criar um ponteiro nulo, tipo:
//Em java eu posso fazer isto Map b; // pronto ja criei um ponteiro pra lugar nenhum, claro que o compilador vai pedir pra inicia-la se eu usar logo abaixo, mas poderia fazer Map b = null; //agora sim, aponta para o limbo //ja em Scala eu nao consigo fazer isto val b: Map //da erro, eu sou obrigado a dar um valor a ele, o mesmo vale pra qualquer tip val c: Int //novamente erro val d: Int = 1 //agora sim //ou melhor val e = 1 //com type inference

Ou seja(ainda to começando com scala, posso por ventura falar alguma asneira ), teoricamente eu nunca terei um ponteiro apontando pra null.

Ahh sim, eu não estava levando em conta esse paradoxo. Desculpem.

fredferrao wrote:Ou seja(ainda to começando com scala, posso por ventura falar alguma asneira ), teoricamente eu nunca terei um ponteiro apontando pra null.

Não? Eu achei que tinha... Em Scala existem tantos nulls (Nothing , Null null, Nil... até o Náim fazem daqui a pouco :p) que é fácil de se perder.

juliocbq wrote:Até em c++. Se você usar a classe template auto_ptr, vai conseguir gerenciar memória como um programa java. O desempenho dela não é muito bom mas a boost tem um set de smartpointers muito bons.

É quase como trabalhar com garbage collection em C++. Quem quiser conhecer, tem uma série de artigos sobre eles no Ponto V!:
http://www.pontov.com.br/site/index.php/cpp/43-smart-pointers

This message was edited 2 times. Last update was at 03/09/2010 08:58:42

Acho que o importante da ausência de null, seria realmente a ausência total do conceito de nulidade.
Ou seja, não adianta ter um objeto que representa o null. Por que aí, o conceito ainda está presente e você fatidicamente ainda terá uma nullpointerexception. Muda-se a os chifres e as manchas, mas o boi continua o mesmo.

Como eliminariamos esse conceito? Em algumas funções que retornam listas, já fazemos isso através da lista vazia (que representa o conjunto vazio). Alguns outros objetos também tem valores que representam a ausência (o vetor (0,0) e a matriz identidade, na matemática, a String "", etc). O interesse do "objeto nulo" é quando ele pode ser usado como um objeto não nulo. É possível fazer for...each numa lista vazia sem obter erro, ou somar um vetor (0,0) com um outro vetor, sem que haja problemas.

Seria possível eliminar isso para os demais métodos ou criar isso para as demais classes? Bem, em métodos que aceitam um parâmetro opcional, certamente poderíamos ter duas assinaturas, uma com um objeto, outra sem. Métodos que retornam um objeto só poderiam retornar listas, e usar-se do conjunto vazio. Em alguns tipos de classes, é possível criar um objeto estático representado o valor vazio (como o "" da String).

Agora, será que isso deixaria os sistemas mais simples? Não sei se com as linguagens atuais. Talvez se implementarmos algum tipo de suporte melhor a conjuntos, isso até poderia ser feito. Coisa que é feita em linguagens funcionais, e daí o sumiço do null no Haskel.

Moderador Membro desde: 23/12/2006 21:05:04 Mensagens: 3083 Offline

Oi,

o NUllPointerException mostra que sua programação esta "furada". Logo, acho importante ter essa Exceção.

Tchauzin!

GUJ Ranger Membro desde: 04/07/2007 18:28:58 Mensagens: 975 Offline

Usar null não é muito diferente de falar palavrão: é possível evitar, mas você está tão acostumado que o usa do mesmo jeito.

O problema principal é que a maioria dos programadores não entendem de máquinas de estado. Talvez porque morcegaram na aula de Linguagens Formais e Autômatos, ou talvez porque nunca tiveram essa disciplina na faculdade. Por não conhecer, usam null como estado da aplicação. Exemplo: uma classe Pedido possui dataEntrega como atributo que, quando for nulo, significa que o pedido ainda não foi entregue. Ou seja, ao invés de evitar o null, torna-o como parte fundamental para o funcionamento do sistema. E olha que existem outras opções, como criar um enum ou usar o pattern State.

Ponteiro null não tem nada de baixo nível, Assembly não tem referências; é apenas uma maneira pobre de pensar sobre uma linguagem.

Haskell e Scala tem opções quanto ao ponteiro null, é basicamente um container que armazena um valor ou nenhum valor. Mas não é só isso, Haskell tem a notação "do" e Scala tem for-compreensions. Ao colocar uma sequência de instruções dentro de um "do"/for-compreension, se uma delas retornar Nothing, as instruções seguintes param de ser executadas e Nothing é retornado no final. É um jeito mais simples do que verificar com ifs cada retorno de programa.

Virtual Machine Man Membro desde: 04/08/2010 09:37:57 Mensagens: 543 Offline

Leonardo3001 wrote:Usar null não é muito diferente de falar palavrão: é possível evitar, mas você está tão acostumado que o usa do mesmo jeito.

Vocês costumam utilizar aquele pattern de NullObject?

Ou ao criar uma enum incluir um valor como INDEFINIDO ?

Procuro fazer isso em aplicações pessoais mas não vejo esse tipo de ténica muito difundida por aí.

Andre Brito wrote:

fredferrao wrote:Ou seja(ainda to começando com scala, posso por ventura falar alguma asneira ), teoricamente eu nunca terei um ponteiro apontando pra null.

Não? Eu achei que tinha... Em Scala existem tantos nulls (Nothing , Null null, Nil... até o Náim fazem daqui a pouco :p) que é fácil de se perder.

Scala tem null, apenas por retrocompatibilidade com .NET e Java, mas seu uso é totalmente desencorajado!

Nil é uma lista vazia. um empty List

GUJ Expert Membro desde: 13/11/2008 12:10:18 Mensagens: 3927 Online

Leonardo3001 wrote:Usar null não é muito diferente de falar palavrão: é possível evitar, mas você está tão acostumado que o usa do mesmo jeito.

...

Ponteiro null não tem nada de baixo nível, Assembly não tem referências; é apenas uma maneira pobre de pensar sobre uma linguagem.

...

Ponteiros são o que há de mais próximo da máquina. Uma maneira de enxergar um bloco de memória. Toda linguagem de programação usa isso, independente no nível, mesmo que seja transparente. Assembly endereça memória da mesma maneira.

Isso aqui é um exemplo simples de ponteiro e endereçamento.

http://www.friedspace.com/assembly/intro.php

Não entendo porque é uma maneira pobre de pensar em uma linguagem. Se for analizar (sistemicamente), não há como evitá-los e eles sempre estarão presentes(a cpu funciona assim).

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