O problema original foi resolvido ?
Abra�os,
Fred.
"Frederico Charle S. Faria" wrote:
> Einar Saukas wrote:
>
> > "Frederico Charle S. Faria" wrote:
> > >
> > > Einar Saukas wrote:
> > >
> > > > "Frederico Charle S. Faria" wrote:
> > > > >
> > > > > Agora o motivo porque os projetores de Java decidiram por isso - exigir o
> > > > > super() na primeira linha impossibilitando mesmo a utiliza��o de vari�veis
> > > > > n�o membros - com certeza foi devido a fatores de complexidade de
> > > > > implementa��o e performanca. ( da MV)
> > > >
> > > > Muito obrigado pelas informa��es, mas eu conhe�o um pouco sobre
> > > > t�cnicas de compila��o e n�o vejo porque a utiliza��o de vari�veis
> > > > locais afetaria significativamente a implementa��o e muito menos a
> > > > performance. Afinal de contas, para um compilador, esse trecho de c�digo:
> > >
> > > Primeiramente voce entendeu errado! A perda de performance e a dificuldade de
> > > implementa��o
> > > n�o se referem a utiliza��o de vari�veis locais , mas sim a decis�o de projeto
> > > dos fundadores do Java
> > > ,ou seja, exigir que o super() seja o primeiro comando do construtor.
> >
> > Na verdade eu n�o entendi errado, � que eu me expressei mal. Eu
> > deveria ter sido mais claro. O que eu quis dizer � que eu n�o vejo porque
> > a utiliza��o de vari�veis locais ANTES DA CONSTRU��O DA CLASSE BASE (AO
> > INV�S DE S� DEPOIS) afetaria significativamente a implementa��o e muito
> > menos a performance.
> >
> > > Espero que perceba a diferen�a, e veja que se fosse de maneira contr�ria a
> > > implementa��o seria mais dif�cil e a
> > > performance com certeza mais pobre!!!
> >
> > Em rela��o ao compilador, eu concordo que a implementa��o seria
> > um pouco mais dif�cil, porque no parser ele teria que sempre verificar
> > se o super() n�o aparece mais "pra frente", depois da inicializa��o de
> > algumas vari�veis locais. Mas isso n�o � t�o complicado assim, a
> > diferen�a no tempo de compila��o dificilmente seria percept�vel, quer
> > dizer, realmente afetaria um pouco a implementa��o mas n�o de forma
> > significativa.
> >
> > J� a performance depende apenas do tempo de interpreta��o do
> > bytecode, algo que n�o � afetado pela complexidade do parser.
> >
> > > > MessageOutputStream() throws java.io.IOException {
> > > > ByteArrayOutputStream tmp = new ByteArrayOutputStream();
> > > > super(tmp); // ERRO!
> > > > }
> > > >
> > > > Tem praticamente a mesma complexidade deste aqui:
> > > >
> > > > MessageOutputStream() throws java.io.IOException {
> > > > super(new ByteArrayOutputStream());
> > > > }
> > >
> > > Voce est� errado! Isto depende da implementa��o do Compilador.. Para C++ , por
> > > exemplo, existem
> > > v�rias implementa��es diferentes para isso! Vejo o livro do Meyers, ele cita
> > > exemplos de implementa��o
> > > deste tipo. Tem compiladores que usam algumas t�cnicas de otimiza��o quando �
> > > utilizada esta �ltima constru��o.
> > > Talvez alguns compiladores Java utilizem esta mesma t�cnica.
> >
> > Mas em rela��o a otimiza��es no c�digo gerado, se houver opera��es
> > envolvendo tempor�rios dentro do construtor, n�o vai fazer realmente muita
> > diferen�a se elas ocorrem antes ou depois da chamada ao construtor da
> > classe base.
> >
> > > > � primeira vista, o compilador s� tem que ser um pouco mais
> > > > cuidadoso na manipula��o da pilha de execu��o, mas isso parece ser
> > > > muito f�cil de resolver. Ser� que tem algum outro fator que eu n�o
> > > > percebi?
> > >
> > > � f�cil de perceber que � mais ineficiente... Imagine um construtor com v�rias
> > > chamadas de m�todos
> > > aninhados, com a implementa��o corrente basta para o compilador analisar a
> > > primeira linha do construtor.
> > > Se n�o fosse assim o compilador teria que analisar toda a a�rvore de m�todos
> > > aninhados para
> > > garantir que n�o houvesse nenhuma referencia a algum atributo da classe antes da
> > > chamada do super.
> > > Mais mem�ria e mais processador!!. Este � um simples exemplo...
> >
> > � verdade, voc� tem raz�o! A quest�o n�o � performance, mas sim
> > a velocidade de compila��o. Os idealizadores do Java deveriam estar
> > preocupados em manter uma sintaxe que permitisse uma compila��o o mais
> > direta poss�vel, para que as ferramentas de desenvolvimento n�o ficassem
> > muito pesadas. Este provavelmente tamb�m foi um dos fatores que os
> > levaram a deixar de fora recursos como sobrecarga de operadores, uma das
> > coisas que tornam a compila��o de C++ algo t�o pesado. OK, muito obrigado
> > pelas informa��es!
> >
> > Essa discuss�o est� bem legal, mas de qualquer forma o problema
> > original continua em aberto: como fazer para instanciar uma classe,
> > repass�-la para o construtor da classe base e depois ainda guard�-la
> > numa vari�vel de inst�ncia?
> >
> > Ou, colocando o problema de outra forma, existe alguma maneira
> > de implementar algo assim:
> >
> > class MessageOutputStream extends ObjectOutputStream {
> > private ByteArrayOutputStream _bos;
> > MessageOutputStream() throws java.io.IOException {
> > super(_bos = new ByteArrayOutputStream()); // ERRO!
> > }
> > }
> >
> > ... de forma que o cliente possa usar essa classe fazendo
> > apenas isto:
> >
> > MessageOutputStream var = new MessageOutputStream();
> >
> > Algu�m tem mais sugest�es?
>
> Talvez isto resolva seu problema:
>
> class MessageOutputStream extends ObjectOutputStream {
> private ByteArrayOutputStream _bos;
> static MessageOutputStream constroi() throws java.io.IOException {
> ByteArrayOutputStream tmp = new ByteArrayOutputStream();
> MessageOutputStream mos = new MessageOutputStream(tmp);
> return mos;
> };
> MessageOutputStream(ByteArrayOutputStream _bosvar) throws java.io.IOException {
> super(_bosvar);
> _bos = _bosvar;
> };
> }
>
> Abra�os,
>
> Fred.
>
> >
> >
> > Um abra�o,
> >
> > Einar Saukas
> > Technical Consultant
> > Summa Technologies, Inc.
> > http://www.summa-tech.com
> >
> > --------------------------- LISTA SOUJAVA ---------------------------
> > http://www.soujava.org.br - Sociedade de Usu�rios Java da Sucesu-SP
> > [para sair da lista: http://www.soujava.org.br/forum/cadastrados.htm]
> > ---------------------------------------------------------------------
>
> --
> Frederico Charles S. Faria
> Especialista em Sistemas
> INATEL - PRODEP
> Fone/Phone: +55 35 471-9280
>
> --------------------------- LISTA SOUJAVA ---------------------------
> http://www.soujava.org.br - Sociedade de Usu�rios Java da Sucesu-SP
> [para sair da lista: http://www.soujava.org.br/forum/cadastrados.htm]
> ---------------------------------------------------------------------
--
Frederico Charles S. Faria
Especialista em Sistemas
INATEL - PRODEP
Fone/Phone: +55 35 471-9280
--------------------------- LISTA SOUJAVA ---------------------------
http://www.soujava.org.br - Sociedade de Usu�rios Java da Sucesu-SP
[para sair da lista: http://www.soujava.org.br/forum/cadastrados.htm]
---------------------------------------------------------------------
