Como assim arguments of reference types are passed in by reference? Por mim
as refer�ncias s�o passadas por valor, assim como tudo em Java. Logo, dentro
de um m�todo, voc� vai estar manipulando uma c�pia de uma refer�ncia. Vai
estar sim, manipulando um mesmo objeto, afinal as duas refer�ncias apontam
para o mesmo lugar. Os objetos, sim, s�o passados por refer�ncia. :)

Talvez dependa do pontos de vista, mas esse � o meu.

Samuel


----- Original Message -----
From: "Gangrel" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, November 07, 2002 8:56 AM
Subject: Re: [java-list] Duvida sobre atribuicao de objetos...


Na verdade, a passagem de obejetos �
por refer�ncia.
D� uma olhada no texto que voc� mesmo
tirou do site da sun.
L� diz:  "..., <b>but the value of an
object is a reference. So the effect
is that arguments of reference types
are passed in by reference. Hence the
name. </b>"

> Continuo afirmando que a passagem de par�metros � por valor. O trecho
abaixo � tirado do Java Tutorial da SUN
(http://java.sun.com/docs/books/tutorial/java/javaOO/arguments.html):
>
>   In Java methods, arguments are passed by value. When invoked, the method
receives the value of the variable passed in. When the argument is of
primitive type, pass-by-value means that the method cannot change its value.
When the argument is of reference type, pass-by-value means that the method
cannot change the object reference, but can invoke the object's methods and
modify the accessible variables within the object.
>   This is often the source of confusion--a programmer writes a method that
attempts to modify the value of one its arguments and the method doesn't
work as expected. Let's look at such method and then investigate how to
change it so that it does what the programmer originally intended.
>
>   Consider this series of Java statements which attempts to retrieve the
current color of a Pen object in a graphics application:
>
> . . .
> int r = -1, g = -1, b = -1;
> pen.getRGBColor(r, g, b);
> System.out.println("red = " + r +
>                    ", green = " + g +
>                    ", blue = " + b);
> . . .
> At the time when the getRGBColor method is called, the variables r, g, and
b all have the value -1. The caller is expecting the getRGBColor method to
pass back the red, green and blue values of the current color in the r, g,
and b variables.
>   However, the Java runtime passes the variables' values (-1) into the
getRGBColor method; not a reference to the r, g, and b variables. So you
could visualize the call to getRGBColor like this: getRGBColor(-1, -1, -1).
>
>   When control passes into the getRGBColor method, the arguments come into
scope (get allocated) and are initialized to the value passed into the
method:
>
> class Pen {
>     int redValue, greenValue, blueValue;
>     void getRGBColor(int red, int green, int blue) {
>         // red, green, and blue have been created
>         // and their values are -1
>         . . .
>     }
> }
> So getRGBColor gets access to the values of r, g, and b in the caller
through its arguments red, green, and blue, respectively. The method gets
its own copy of the values to use within the scope of the method. Any
changes made to those local copies are not reflected in the original
variables from the caller.
>   Now, let's look at the implementation of getRGBColor within the Pen
class that the method signature above implies:
>
> class Pen {
>     int redValue, greenValue, blueValue;
>     . . .
>         // this method does not work as intended
>     void getRGBColor(int red, int green, int blue) {
>         red = redValue;
>         green = greenValue;
>         blue = blueValue;
>     }
> }
> This method will not work as intended. When control gets to the println
statement in the following code, which was shown previously, getRGBColor's
arguments, red, green, and blue, no longer exist. Therefore the assignments
made to them within the method had no effect; r, g, and b are all still
equal to -1.
> . . .
> int r = -1, g = -1, b = -1;
> pen.getRGBColor(r, g, b);
> System.out.println("red = " + r +
>                    ", green = " + g +
>                    ", blue = " + b);
> . . .
> Passing variables by value affords the programmer some safety: Methods
cannot unintentionally modify a variable that is outside of its scope.
However, you often want a method to be able to modify one or more of its
arguments. The getRGBColor method is a case in point. The caller wants the
method to return three values through its arguments. However, the method
cannot modify its arguments, and, furthermore, a method can only return one
value through its return value. So, how can a method return more than one
value, or have an effect (modify some value) outside of its scope?
>   For a method to modify an argument, it must be of a reference type such
as an object or array. Objects and arrays are also passed by value, but the
value of an object is a reference. So the effect is that arguments of
reference types are passed in by reference. Hence the name. A reference to
an object is the address of the object in memory. Now, the argument in the
method is referring to the same memory location as the caller.
>
>   Let's rewrite the getRGBColor method so that it actually does what you
want. First, you must introduce a new type of object, RGBColor, that can
hold the red, green and blue values of a color in RGB space:
>
> class RGBColor {
>     public int red, green, blue;
> }
> Now, we can rewrite getRGBColor so that it accepts an RGBColor object as
an argument. The getRGBColor method returns the current color of the pen by
setting the red, green and blue member variables of its RGBColor argument:
> class Pen {
>     int redValue, greenValue, blueValue;
>     void getRGBColor(RGBColor aColor) {
>         aColor.red = redValue;
>         aColor.green = greenValue;
>         aColor.blue = blueValue;
>     }
> }
> And finally, let's rewrite the calling sequence:
> . . .
> RGBColor penColor = new RGBColor();
> pen.getRGBColor(penColor);
> System.out.println("red = " + penColor.red +
>                    ", green = " + penColor.green +
>                    ", blue = " + penColor.blue);
> . . .
> The modifications made to the RGBColor object within the getRGBColor
method affect the object created in the calling sequence because the names
penColor (in the calling sequence) and aColor (in the getRGBColor method)
refer to the same object.
>
> ---
> Jonatan Schroeder
> [EMAIL PROTECTED]
>
>
>   ----- Original Message -----
>   From: Carlos Eduardo Carvalho
>   To: [EMAIL PROTECTED]
>   Sent: Tuesday, November 05, 2002 8:29 AM
>   Subject: Re: [java-list] Duvida sobre atribuicao de objetos...
>
>
>   Jonatan,
>
>   Essa � uma afirma��o perigosa de ser feita. N�o sei se a passagem de
par�metros em Java seria exatamente por valor, ao inv�s de por refer�ncia.
Nesse mesmo exemplo que voc� citou na mensagem abaixo, pode ser simulada uma
situa��o onde fica clara essa contradi��o.
>
>   Vamos supor que tenhamos dois m�todos, executar() e metodoAtribuicao(),
como seguem abaixo.
>
>   public void executar() {
>       MeuBean a = new MeuBean();
>       MeuBean b = new MeuBean();
>
>       a.setNome("Teste Atribuicao");
>
>       metodoAtribuicao(a, b);
>
>       System.out.println("Bean A: "+a.getNome()); // A impress�o na
console da
>       System.out.println("Bean B: "+b.getNome()); // aplica��o ter� o
mesmo valor
>   }
>
>   public void metodoAtribuicao(MeuBean a, MeuBean b) {
>       b.setNome(a.getNome());
>   }
>
>   A partir desta justificativa creio que seja mais correto dizer que a
passagem de par�metros de objetos em m�todos seja por refer�ncia, enquanto
que a passagem de par�metros de tipos b�sicos do java em m�todos seja por
valor. � uma quest�o meio confusa de se afirmar, mas se estiver errado,
corrijam-me!
>
>   Falou!
>
>   Carlos Eduardo Teixeira Carvalho
>   Analista de Sistemas - F�brica de Software
>   Unitech Tecnologia de Informa��o
>
>     ----- Original Message -----
>     From: Jonatan Schroeder
>     To: [EMAIL PROTECTED] ; Sr. Apocalipse
>     Sent: Monday, November 04, 2002 7:09 PM
>     Subject: Re: [java-list] Duvida sobre atribuicao de objetos...
>
>
>     A passagem de par�metros em java � por valor, e n�o por refer�ncia.
Ent�o,
>
>     public void metodo_atribuicao(Object a, Object b) {
>         a = b;
>     }
>
>     n�o tem efeito algum. O objeto 'a' � passado ao m�todo, mas quando
voc� faz a atribui��o, voc� est� fazendo com que o par�metro a seja
alterado, ou seja, ele deixa de apontar para o local em que foi definido na
chamada do m�todo e passa a apontar para o local do objeto b.
>
>     ---
>     Jonatan Schroeder
>     [EMAIL PROTECTED]
>
>
>       ----- Original Message -----
>       From: Sr. Apocalipse
>       To: [EMAIL PROTECTED] ; [EMAIL PROTECTED]
>       Sent: Monday, November 04, 2002 2:22 PM
>       Subject: [java-list] Duvida sobre atribuicao de objetos...
>
>
>       Galera,
>       Eu gostaria que algu�m me esclarecesse o seguinte ocorrido.
>       Eu queria fazer uma atribuicao de dois objetos dentro de um metodo e
nao
>       consegui, quando retorna do metodo a atribuicao � desfeita. Fora do
metodo a
>       atribuicao ocorre e um "aponta" para o outro.
>       O exemplo est� abaixo:
>
>       public void teste(){
>
>          Object a, b;
>
>          a = new Vector();
>          b = new Date();
>
>          metodo_atribuicao(a, b);
>          // Apos o metodo_atribuicao, o objeto a nao esta "apontando" para
o
>       objeto b
>         // ou seja, o objeto a continua como Vector e o objeto b como
Date.
>
>         a = b;
>         // Agora sim o objeto a "aponta" para o objeto b
>         // ou seja, o objeto a agora � Date e o objeto b tambem
>       }
>
>       public void metodo_atribuicao(Object a, Object b) {
>           a = b;
>       }
>
>
_______________________________________________________________________
>       Yahoo! GeoCities
>       Tudo para criar o seu site: ferramentas f�ceis de usar, espa�o de
sobra e acess�rios.
>       http://br.geocities.yahoo.com/
>
>       ------------------------------ LISTA
SOUJAVA ----------------------------
>       http://www.soujava.org.br  -  Sociedade de Usu�rios Java da
Sucesu-SP
>       d�vidas mais comuns: http://www.soujava.org.br/faq.htm
>       regras da lista: http://www.soujava.org.br/regras.htm
>       historico: http://www.mail-archive.com/java-list%40soujava.org.br
>       para sair da lista: envie email para
[EMAIL PROTECTED]
>       --------------------------------------------------------------------
-----
>

________________________________________________________
Paulo "gangrel-br" R. C. Siqueira
Programador e Fan�tico por Jogos :)
Mogi das Cruzes - SP


__________________________________________________________________________
Encontre sempre uma linha desocupada com o Discador BOL!
http://sac.bol.com.br/discador.html
Ainda n�o tem AcessoBOL? Assine j�! http://sac.bol.com.br



------------------------------ LISTA SOUJAVA ----------------------------
http://www.soujava.org.br  -  Sociedade de Usu�rios Java da Sucesu-SP
d�vidas mais comuns: http://www.soujava.org.br/faq.htm
regras da lista: http://www.soujava.org.br/regras.htm
historico: http://www.mail-archive.com/java-list%40soujava.org.br
para sair da lista: envie email para [EMAIL PROTECTED]
-------------------------------------------------------------------------





------------------------------ LISTA SOUJAVA ---------------------------- 
http://www.soujava.org.br  -  Sociedade de Usu�rios Java da Sucesu-SP 
d�vidas mais comuns: http://www.soujava.org.br/faq.htm
regras da lista: http://www.soujava.org.br/regras.htm
historico: http://www.mail-archive.com/java-list%40soujava.org.br
para sair da lista: envie email para [EMAIL PROTECTED] 
-------------------------------------------------------------------------

Responder a