Здравствуйте, msqrt84, Вы писали:

M>Вы хотите сказать, что если сделать вот так
[...]
M>будет выводится "5"?

Не будет. В 1.4 и в 1.5 и предыдущих версиях классы Integer, Double и иже с ним дубли примитивов все немутабельные (нет методов-мутаторов, типа setЧегоТоТам). Поэтому при передаче по ссылке стандартного завертыша в Integer(int) получим точно такой же результат 0.

Почему так происходит (пример для java 1.4, для java 1.5 будет то же самое, только без оборачиваний, например Integer n = 0, работать будет одинаково).

 private static void change(Integer ch) // ch содержит ссылку на объект Integer со значением 0
 {
  // при этом ch находится в контексте функции change и имеет совсем разное значение, нежели n внутри main.
    // то есть по сути это две разные ссылки, указывающие на один объект на данном этапе
    ch = new Integer(6); // ch теперь содержит ссылку на объект Integer со значением 6, а n внутри main продолжает содержать ссылку на объект Integer со значением 0
 }
 
 public static void main(String[] args)
 {
    Integer n = new Integer(0); // переменной n устанавливается ссылка на объект Integer со значением 0
    change(n);
    System.out.println(n);
 }

То есть если хочется поменять, то необходимо оборачивать не в стандартный Integer, а какой-нибудь свой, у которого будет метод-мутатор для изменения его состояния, например, setValue. Как — было показано ниже.

T>Создать класс с данными религия не позволяет?
Т.е. сделать класс "пара массивов даблов для расчёта корреляции и девиации"? Промолчу насчёт лезвия Оккама, хотелось бы просто поинтересоваться, как вы это себе представляете? Хранить в нём помимо массивов ещё поля для хранения промежуточных значений и флаги, что они уже посчитаны или нет? Вот красивое решение.

T> Тогда используйте массивы для передачи и возврата значений, от этого еще никто не умирал, красоты мало, зато первоманс высокий.
Перформанс высокий на голом С. Java — это решение немного поступиться перпомансом в пользу понятного и надёжного кода. Ну так вот, использование массивов — это отказ от статической (т.е. средставим компилятора) проверки числа аргументов, их порядка и, зачастую, пита. К каким опасностям это ведёт, думаю, очевидно. И чем это лучше передачи объектов byref, единственным минусом которого, как тут уже отмечалось, является то, что кто-то может написать byref там, где он не нужен, а пользователям этого кода потом будет плохо. (Аналогичная ситуация возникает, если метод в С++ забыли обозначить как const, хотя реально он таковым является).

R>Беря в руки ООЯ научитесь уже думать объектно, а не процедурно:

package ru.rsdn.test;
И какую же сущность инкапсулирует этот класс?

R>}

Не верите, посмотрите классы java.util.Collection. Наверно Sun можно в этом вопросе доверять?

Да верю. Только вот интерфейс у класса получается странный. Если раньше у нас получение значений было атомарной операцией, то теперь нет. И имея объект класса невозможно узнать, посчитаны ли уже минимумы и максимумы или нет.
И вообще, я не согласен, что если у нас два или более значения, связынных между собой, то нужно обязательно их в класс объединять.

Здравствуйте, Евгений Коробко, Вы писали:

ЕК>И какую же сущность инкапсулирует этот класс?
По сути это коллекция с возможностью поиска максимального и минимального элемента. По уму лучше наверно наследоваться от какой-либо готовой коллекции пакета java.util.* и дописать нужный функционал.
Можно также посмотреть в сторону рефлексии — java.lang.reflect.Array.

ЕК>Да верю. Только вот интерфейс у класса получается странный. Если раньше у нас получение значений было атомарной операцией, то теперь нет. И имея объект класса невозможно узнать, посчитаны ли уже минимумы и максимумы или нет.
Согласен, все зависит от ТЗ на такой класс. К примеру, метод eval может вызываться автоматически в конструкторе и при изменении содержимого массива, а не только по требованию извне.

ЕК>И вообще, я не согласен, что если у нас два или более значения, связынных между собой, то нужно обязательно их в класс объединять.
Объектный и абстрактный подход родили такой столп ООП, как инкапсуляция. Против него быть невозможно, можно или следовать ему, а значит ООП, или не следовать, а значит следовать какой-либо другой парадигме.
PS Есть такой мультфильм "Баба-яга против!".

R>Объектный и абстрактный подход родили такой столп ООП, как инкапсуляция. Против него быть невозможно, можно или следовать ему, а значит ООП, или не следовать, а значит следовать какой-либо другой парадигме.

Не вижу, как это связано с необходимостью создавать класс, чтобы хранить минимальное и максимальное значение коллекции. И уж тем более странно выглядит предложение унаследоваться от коллекции. От какой именно? Ото всех? И это вместо функции, которая, по идее, примнимает интерфейс IEnumerable?

В то время, как тенденция современного программирования постепенно уходит от идеи создания разветвлёных деревьев наследования в сторону интерфейсно-ориентированного подхода и всевозможных патернов по "склейке" независимых классов по тем или иным схемам, вы предлагаете откровенно злоупотребялть наследование, за уши его притягивая туда, куда не надо? Ведь есть класс java.util.Arrays, который как раз сделан так, как я и предлагаю. В С++ есть модуль algorithm. Это что, по-вашему, нарушение ООП?

Здравствуйте, Евгений Коробко, Вы писали:

ЕК>В то время, как тенденция современного программирования постепенно уходит от идеи создания разветвлёных деревьев наследования в сторону интерфейсно-ориентированного подхода и всевозможных патернов по "склейке" независимых классов по тем или иным схемам, вы предлагаете откровенно злоупотребялть наследование, за уши его притягивая туда, куда не надо?
Нет, вы превратно меня поняли.
Вы привели словесное описание и попросили привести пример, как это реализуется на объектах, вам был дан ответ. Но (!) я не говорил, что любой другой (не объектный) вариант реализации неверен.

ЕК> Ведь есть класс java.util.Arrays, который как раз сделан так, как я и предлагаю. В С++ есть модуль algorithm. Это что, по-вашему, нарушение ООП?
Класс Arrays полностью статичный — не противоречит, просто из другой оперы.
Вот интересная цитата:

Традиционная компьютерная система, основанная на так называемой аппаратной архитектуре фон Неймана (Von Neumann architecture), может рассматриваться как множество функций или процессов, работающих с набором данных, хранимых либо в памяти, либо на диске — это не принципиально. Эта статическая архитектурная модель показана на рис. 1.1. Из рисунка видно, что в процессе работы системы динамика состоит в вызове некоторой функции f(1), которая считывает соответствующие данные A, преобразовывает их и записывает в B. Потом вызывается некоторая другая функция f(2), которая тоже считывает некоторые данные (возможно, те же), использует их по назначению и записывает в C. Подобный перекрывающийся доступ к данным порождает проблемы параллельной обработки и целостности, которые могут быть разрешены с помощью систем управлениябазами данных. Перед тем как двигаться дальше, стоит рассмотреть вопрос, что нужно сделать, чтобы изменить часть структуры данных.

Рассматривая это с точки зрения специалиста по поддержке программы, можно сделать единственный вывод: необходимо проверить, затрагивают ли эти изменения каждую отдельную функцию. В этом вопросе может помочь качественная документация, но на практике она доступна редко. Отчасти это объясняется тем, что хорошая документация сама должна состоять из объектноориентированного описания системы, и ее невозможно представить в отрыве от объектноориентированной реализации или, по крайней мере, проектного решения. Кроме того, изменение каждой функции в соответствии с новыми структурами данных может иметь побочный эффект в других частях системы. Возможно, это объясняет необычайно высокую стоимость поддержки программных систем.

На рис. 1.2 показан совершенно иной архитектурный подход к системам. Все данные, доступ к которым нужен функции, инкапсулируются в один пакет с этой функцией — так называемый объект (object) — таким образом, чтобы другой объект не имел доступа к этим данным. Используя аналогию, предложенную Стивом Куком (Steve Cook), можно рассматривать эти объекты как яйца. Желток — это структура данных, белки состоят из функций, которые имеют доступ к этим данным, а скорлупа представляет сигнатуру общедоступных операций. Оболочка интерфейса скрывает реализацию и самих функций, и структур данных. Предположим, что в яйце, изображенном “в разрезе” на рис. 1.2, изменилась структура данных. Тогда специалисты по сопровождению должны проверить только факт влияния изменений на белок этого яйца; сфера вмешательства локализована. Изменение реализации одного объекта не может затронуть “внутренность” другого. В этом и состоит инкапсуляция: данные и процессы объединяются и скрываются за интерфейсом.

(c) ссылка на источник уже есть в теме

Здравствуйте, rsn81, Вы писали:

R>Здравствуйте, Евгений Коробко, Вы писали:


ЕК>> Ведь есть класс java.util.Arrays, который как раз сделан так, как я и предлагаю. В С++ есть модуль algorithm. Это что, по-вашему, нарушение ООП?
R>Класс Arrays полностью статичный — не противоречит, просто из другой оперы.
R>Вот интересная цитата:

браво, дальше идет цитата, которая полностью противоречит устройству java.util.Arrays

где там у java.util.Arrays "желток" ?

PS ну и сравнения в этой статье

Здравствуйте, Тычеблин, Вы писали:

Т>где там у java.util.Arrays "желток" ?
1. Вы разницу между терминами класс и объект знаете?
2. Вообще с самого начала темы говорилось
Re[3]: передача параметра "по ссылке"

Автор: rsn81
Дата: 21.12.06

, что в Java static само по себе (!), то есть, к примеру, класс, содержащий только статичные члены — процедурное программирование, неужто это нужно еще повторить n-ый раз повторить?

Здравствуйте, Евгений Коробко, Вы писали:

T>>Создать класс с данными религия не позволяет?
ЕК>Т.е. сделать класс "пара массивов даблов для расчёта корреляции и девиации"? Промолчу насчёт лезвия Оккама, хотелось бы просто поинтересоваться, как вы это себе представляете? Хранить в нём помимо массивов ещё поля для хранения промежуточных значений и флаги, что они уже посчитаны или нет? Вот красивое решение.

T>> Тогда используйте массивы для передачи и возврата значений, от этого еще никто не умирал, красоты мало, зато первоманс высокий.
ЕК>Перформанс высокий на голом С. Java — это решение немного поступиться перпомансом в пользу понятного и надёжного кода.

Пишите на С или хоть на Ассемблере, как вам угодно. Если бы Sun по каждый раз меняла язык, то получилось бы как с .Net, что приложения написанные под первую версию не работают под второй и надо все переписывать, вы себе представляете как можно переписать банковскую систему, работающую и отлаженную и во что это выльется. Не видели создатели большой необходимости, и не добавили, и я с ними в этом согласен. Есть гораздо более насущные проблемы, чем охота за наносекундами.

ЕК>Ну так вот, использование массивов — это отказ от статической (т.е. средставим компилятора) проверки числа аргументов, их порядка и, зачастую, пита. К каким опасностям это ведёт, думаю, очевидно. И чем это лучше передачи объектов byref, единственным минусом которого, как тут уже отмечалось, является то, что кто-то может написать byref там, где он не нужен, а пользователям этого кода потом будет плохо. (Аналогичная ситуация возникает, если метод в С++ забыли обозначить как const, хотя реально он таковым является).

Не нравятся массивы используйте parameter template, как тут уже писали. Вы из мухи делаете слона. Поищите в сети тесты на FFT на Java.

http://citeseer.ist.psu.edu/698408.html

Резюме — скорость программ на java достигает 50-70% от скорости программ на C. Причем это для тестов на версии jdk 1.3. Я лично готов пожертвовать процентами первоманса в угоду надежности.

T>Если бы Sun по каждый раз меняла язык, то получилось бы как с .Net, что приложения написанные под первую версию не работают под второй

В .NET изначально продумали этот момент и ничего не мешает иметь на одном компьютере столько версий .NET, сколько нужно.

Здравствуйте, Евгений Коробко, Вы писали:

ЕК>В .NET изначально продумали этот момент и ничего не мешает иметь на одном компьютере столько версий .NET, сколько нужно.
Прошу прощения за offtop, но IIS v5.1 + (ASP.NET 2.0.50727 + ASP.NET 1.1.4322) имеет серьезную проблему: два сайта на разный фреймворках не могут работать в одном пуле приложений — в IIS v6 (Windows 2003 Server) эта проблема решена, а как там быть.

А JRE на одном хосте может быть столько, сколько копий каталога JRE: скопировал каталог JRE в текущий путь с исполняемой программой — готово. Тем более это разрешено лицензией Sun... как таким образом поступать с .NET, гм... он же куда только не кладет себя.

Так что вроде бы все совсем наоборот в действительности.

мои пять копеек в тему:
1) Упопянули что введедение pass by ref фукциональности вызовет проблемы совместимости кода. Не вижу как и где. Просто новый код будет требовать соответсвующую версию JVM. Ведь никто же не требует чтоб приложение разработанное для версии n.m работало на версии n.m-1
2) Язык программирования универсальный инструмент и если для одного проекта ООП это good то для другого 5% performance гораздо более важно чем соблюдение канонов ООП. Да можно использовать C# который имеет эту функциональность, но иногда JAVA единственный выбор и разводить зоопарк языков ради такого пустяка никто не хочет. Так что если уж хочешь быть унивесальным то будь добр соотвествуй.
3) Защитники приципов ООП в этой ветке слепо цитируют выдержки из своей "библии ООП" а это уже смахивает на фанатизм. Беспрестрастно оцените ситуацию, очевидно что привильное использование этого функционала добаит универсальности языку. А если быть идиотом то следование канонам ООП не спасет вас от глюков и нечитаемого кода.

PS Такое чуство возникает что разработчики просто поленились добавить эту фичу

Здравствуйте, Аноним, Вы писали:

А>мои пять копеек в тему:
А> 1) Упопянули что введедение pass by ref фукциональности вызовет проблемы совместимости кода. Не вижу как и где. Просто новый код будет требовать соответсвующую версию JVM. Ведь никто же не требует чтоб приложение разработанное для версии n.m работало на версии n.m-1
А> 2) Язык программирования универсальный инструмент и если для одного проекта ООП это good то для другого 5% performance гораздо более важно чем соблюдение канонов ООП. Да можно использовать C# который имеет эту функциональность, но иногда JAVA единственный выбор и разводить зоопарк языков ради такого пустяка никто не хочет. Так что если уж хочешь быть унивесальным то будь добр соотвествуй.


А>PS Такое чуство возникает что разработчики просто поленились добавить эту фичу

There are good reasons that Java excluded the idea of pass-by-reference from its language design, and when writing Java applications it's best to do as Java does. There are elegant solutions to all common problems that may be solved with pass-by-reference in other languages. Before I get there, though, let's look at some of the problems of pass by reference.

Pass by reference mixes inputs and outputs of code. This is the fundamental problem with the technique. In Java, a programmer can assume that variables will not change their value when passed as parameters to a method. In languages with pass by reference semantics, this basic assumption cannot be made.

Pass by reference confuses the interface to a method. Methods written using pass-by-reference semantics can have extremely complex interfaces that are difficult for client programmers to learn and understand. That said, you may be left with a situation where you feel the need to use pass-by-reference in an application. There are two major reasons to use pass by reference, and each has its own solution:

First, pass by reference is used in many languages to reduce the costs of a method call, preventing the copying of large amounts of data. This is a non-issue in Java. The problem is solved by simply realizing that in Java, the values passed to a method are either primitive data or object references, which cannot be large enough to make this a real issue. Objects themselves can be very large, but are never passed to methods.

Second, pass by reference allows the variable to be changed, and the changed value can be seen in client code. The solution here is to refactor the application to use the return value for this purpose. If a parameter is an "in-out" parameter, then its original value should be passed into the method and its result moved to the return value.

http://www.yoda.arachsys.com/java/passing.html

А> 3) Защитники приципов ООП в этой ветке слепо цитируют выдержки из своей "библии ООП" а это уже смахивает на фанатизм. Беспрестрастно оцените ситуацию, очевидно что привильное использование этого функционала добаит универсальности языку. А если быть идиотом то следование канонам ООП не спасет вас от глюков и нечитаемого кода.

А не правильное использование by ref добавит лишних проблем пользователям и разработчикам. С++ вот если правильно использовать, то ведь можно отличные программы писать, только вот что-то почему-то немногие пишут программы на нем без memory leaks, и access violation. Если почитать ветку с++, то можно увидеть, что прогеры вместо решения прикладных проблем воют с языком, бустами, изобретают велосипеды кастомные memory manager'ы. Никому не нужен сложный перегруженный язык, вот generics ввели, так сразу многие начали плеваться. Давайте еще yield введем, потом еще чего-нибудь и в конце концов язык превратится в C++, и правильно на нем писать будут единицы, а остальные плодить код, который только на свалку. В конце концов, кого Java не устраивает в том виде в котором существует, можно написать свой язык под JVM благо исходники для всех открыты.

Здравствуйте, Аноним, Вы писали:

А>мои пять копеек в тему:
А> 1) Упопянули что введедение pass by ref фукциональности вызовет проблемы совместимости кода. Не вижу как и где. Просто новый код будет требовать соответсвующую версию JVM. Ведь никто же не требует чтоб приложение разработанное для версии n.m работало на версии n.m-1
А> 2) Язык программирования универсальный инструмент и если для одного проекта ООП это good то для другого 5% performance гораздо более важно чем соблюдение канонов ООП. Да можно использовать C# который имеет эту функциональность, но иногда JAVA единственный выбор и разводить зоопарк языков ради такого пустяка никто не хочет. Так что если уж хочешь быть унивесальным то будь добр соотвествуй.

В догонку, универсальные средства никогда не дадут того выигрыша в конкретном применение, как средства ускоспециализированные. Никто не пишет большие распределенные системы на бейсике или ассемблере, а драйвера — на java. Причем проблема универсальность vs ускозаточенность свойствена не только языкам. Иначе бы, к примеру, многоборцы часто завоевывали места в отдельных дисциплинах. Так что использовать надо те средства, которые лучше всего подходят для решения конкретной задачи либо идти на осознанный компромисс.
Java достаточно универсальный язык, но требовать, чтобы он везде был лучше остальных. Это из разряда: и с ёлки съехать, и ж... не обколоть. Так не бывает!

Продолжим продуктивную дискуссию

Здравствуйте, Trean, Вы писали:

T>А не правильное использование by ref добавит лишних проблем пользователям и разработчикам. С++ вот если правильно использовать,.....

T>В догонку, универсальные средства никогда не дадут того выигрыша в конкретном применение, как средства ускоспециализированные. Никто не пишет большие распределенные системы на бейсике или ассемблере,...


Тут вы уже лукавите сравниваем не c++ и Java а .NET (c#, ...) и Java. Давайте всетаки сравнивать языки более или менее одной весовой категории.
А так совершенно верно, универсальность достается ценой производительности. И вообще этот спор больше похож на спор тупоконечников и остроконечников. У каждой стороны есть свои аргументы. Решать кто прав кто виноват будет время, то что необходимо останется, то что ненужно отомрет в ходе эволюции. Я лично использую C# и пользуюсь pass by ref. Не считаю что это делает мой код менее читаемым.

Если уж подходить с точки зрения читаемости кода то запоминать лишние обертки под простые типы или типы созданные специально для возврата значений (которые будут разные от проекта к проекту так как их пишут разные люди) для меня сложнее чем выучить одно ключевое слово ref(стандарт языка и он неизменен от проекта к проекту).

Евгений Коробко wrote:
> int[] GetMinMaxValues(int[] values)
> понять, сколько значений она возвращает и в каком порядке?
Варианты:

public class Holder<T>
{
    T var;
    Holder(){}
    Holder(T var){this.var=var;}
    T get(){return var;}
    void set(T var){this.var=var;}
}

...
public void getMinMaxValues(int []values,Holder<int> min, Holder<int> max)
...

public static class MinMaxRes
{
    int min,max;
};
public MinMaxRes getMinMaxValues(int []values)

А вообще, ХАЧУ ТУПЛЫ!

Здравствуйте, Аноним, Вы писали:


А> 2) Язык программирования универсальный инструмент и если для одного проекта ООП это good то для другого 5% performance гораздо более важно чем соблюдение канонов ООП. Да можно использовать C# который имеет эту функциональность, но иногда JAVA единственный выбор и разводить зоопарк языков ради такого пустяка никто не хочет. Так что если уж хочешь быть унивесальным то будь добр соотвествуй.

Я бы сказал, что тащить в язык все г..но, которое реализовано в библиотеках, ради пары идиотов, которые

по другому не могут

и превращать язык в очередной C# это идиотизм. Кому надо, вернее, кто по другому не может, пусть идет на Nemerle.org и C#. Или соответственно, учится нормально программировать, а то так недолго и в дворники попасть по сокращению штатов

Здравствуйте, Аноним, Вы писали:

А>Продолжим продуктивную дискуссию

Ок. Хотя тут все вроде как остались при своем мнении

А>Тут вы уже лукавите сравниваем не c++ и Java а .NET (c#, ...) и Java. Давайте всетаки сравнивать языки более или менее одной весовой категории.

http://msdn2.microsoft.com/en-us/library/x53a06bb.aspx

http://java.sun.com/docs/books/tutorial/java/nutsandbolts/_keywords.html

С# (83 ключевых слов) vs Java (50 ключевых)

Мне C#-вский зоопарк кейвордов в Java не нужен, только чтобы получать дополнительно 5% первоманса

А>А так совершенно верно, универсальность достается ценой производительности. И вообще этот спор больше похож на спор тупоконечников и остроконечников. У каждой стороны есть свои аргументы. Решать кто прав кто виноват будет время, то что необходимо останется, то что ненужно отомрет в ходе эволюции. Я лично использую C# и пользуюсь pass by ref. Не считаю что это делает мой код менее читаемым.

Вопрос не только и не столько в читаемости, а в усложнении разработки, трудности вхождения новичков и переобучения, а это все деньги. Часть из того, что в C# достигается через языковые конструкции в Java достигается через JNI, а там можно писать на чем угодно. Тащить в язык, все что может пригодиться в 1% случаев — оверхед, проще использовать для этого специальные тулы. В качестве примера сошлюсь на JAI (Java Advanced Imaging), в котором код всякого рода копирований, свертки, корреляции написан на C/Asm и оптимизирован под возможности и simd расширения различных платформ (mmx, 3dnow). И ведь работает и вполне быстро. Почему-то разработчиков Red5 (открытый потоковый сервер видео) Java вполне устроил, надо видео конвертнуть в другой формат — подключай кроссплатформенный ffmpeg написанный на С и будет тебе первоманс. На Java отлично реализуется бизнес логика, управление объектами, для низкоуровневых вещей есть лучше средства, хотя не всегда их применение даст огромный выигрыш по сравнению с pure java.

А>Если уж подходить с точки зрения читаемости кода то запоминать лишние обертки под простые типы или типы созданные специально для возврата значений (которые будут разные от проекта к проекту так как их пишут разные люди) для меня сложнее чем выучить одно ключевое слово ref(стандарт языка и он неизменен от проекта к проекту).

А сколько еще случаев будет, когда вам захочется, чтобы добавили новое ключевое слово? И только для того, чтобы использовать его в 1% своего кода.

Здравствуйте, Trean, Вы писали:

T>Вопрос не только и не столько в читаемости, а в усложнении разработки, трудности вхождения новичков и переобучения, а это все деньги. Часть из того, что в C# достигается через языковые конструкции в Java достигается через JNI, а там можно писать на чем угодно. Тащить в язык, все что может пригодиться в 1% случаев — оверхед, проще использовать для этого специальные тулы. В качестве примера сошлюсь на JAI (Java Advanced Imaging), в котором код всякого рода копирований, свертки, корреляции написан на C/Asm и оптимизирован под возможности и simd расширения различных платформ (mmx, 3dnow). И ведь работает и вполне быстро. Почему-то разработчиков Red5 (открытый потоковый сервер видео) Java вполне устроил, надо видео конвертнуть в другой формат — подключай кроссплатформенный ffmpeg написанный на С и будет тебе первоманс. На Java отлично реализуется бизнес логика, управление объектами, для низкоуровневых вещей есть лучше средства, хотя не всегда их применение даст огромный выигрыш по сравнению с pure java.
Описывал совсем аналогичное ощущение: http://rsdn.ru/Forum/Message.aspx?mid=2248849

Автор: rsn81
Дата: 05.12.06

Здравствуйте, dev_m, Вы писали:

_>Как в java сделать так, чтобы измененный в функции параметр, вернулся в основную программу.

Как в старом анекдоте: и жопу показывал, и унитаз приносил, а туалетную бумагу так и не дали...

static void set(int[] nByRef)
{
    nByRef[0] = 5;
}

public static void main(String[] args)
{
    int[] nRef = { 1 };
    System.out.print(nRef[0]);
    set(nRef);
    System.out.print(nRef[0]);
}

или

class Ref<T> {
    public T v;

    Ref(T v) {
        this.v = v;
    }
}

public class Main {
    static void main(String[] args) {
        Ref<String> ref = new Ref<String>("1");
        System.out.print(ref.v);
        set(ref);
        System.out.print(ref.v);
    }

    static void set(Ref<String> ref) {
        ref.v = "5";
    }
    
}