Przekazywanie wielu argumentow

[Jacek Czerwinski]

Mam od jakiego� czasu coraz wi�cej dualizmu, podw�jne metody (lub
konstruktory) z tablic� i list� argument�w.

Dodam, �e na gruncie Javy 6 wi�c intensywnie z trzech kropeczek korzystam ;)

doSomething(List<Type> arg)
i
doSomething(Type arg1, Type ... args)
// lub doSomething(Type ... args) jak dopuszczam zero argumentow

Z zewn�trz to API jest bardzo wygodne, kod ze zmienn� ilo�ci� arg jest
bardzo czytelny itd. jak tzreba budowac dynamicznie to List.

Wewn�trz jedna z form 'kontenera' jest konwertowana do drugiej i w
kodzie wewn�trznym wyst�puje ju� w jednej postaci.

Jak wracam do kodu z r�nych okres�w, to raz jest tablica konwertowana
do listy, innym razem na odwr�t.

Jak by by�o lepiej? Joushua Bloch krzywi si� na tablice, �e s� sztywne i
odstaj� od reszty j�zyka. Z drugiej strony final tab[] (do��) �adnie
wyra�a ostateczn� posta� tych danych. W 95% s� to dane od pewnej chwili
sztywne (kontener siďż˝ potem nie zmienia)

P�tle oczywi�cie w notacji for-each
for(Type t: kontener) {}
wi�c one nawet nie zdradzaj� r�znicy w implementacji.

Jak by�cie g�osowali na wewn�trzn� implementacj�?

[Brzezi]

�ro, 30 gru 2009 o 16:34 GMT, Jacek Czerwinski napisa�(a):

> Jak by�cie g�osowali na wewn�trzn� implementacj�?

Przy zmiennej liczbie argumentow zawsze dostajesz tablice tych argumentow,
w innych sytuacjach wygodnie jest stosowac interfejs List, albo nawet
Collection...

Pozdrawiam
Brzezi

[Jacek Czerwinski]

Brzezi pisze:

Dok�adnie to mam na my�li, kropki to tablica ;)

Pytanie, kt�re zredaguj� inaczej: je�li dostarczam OBA interfejsy, tzn
tablic� i do wyboru List //by� mo�e Collection, dzi�ki za
przypomnienie//, kt�ry zrobi� wrapperem nad kt�rym, kt�r� struktur�
wybra� do wewn�trznej implementacji, bo ta oczywi�cie jest jedna.

[Michal Kleczek]

Jacek Czerwinski wrote:

> Brzezi pisze:
>> śro, 30 gru 2009 o 16:34 GMT, Jacek Czerwinski napisał(a):
>>
>>> Jak byście głosowali na wewnętrzną implementację?

>>
>> Przy zmiennej liczbie argumentow zawsze dostajesz tablice tych
>> argumentow, w innych sytuacjach wygodnie jest stosowac interfejs List,
>> albo nawet Collection...
>

> Dokładnie to mam na myśli, kropki to tablica ;)
>
> Pytanie, które zredaguję inaczej: jeśli dostarczam OBA interfejsy, tzn
> tablicę i do wyboru List //być może Collection, dzięki za
> przypomnienie//, który zrobić wrapperem nad którym, którą strukturę
> wybrać do wewnętrznej implementacji, bo ta oczywiście jest jedna.

Odpowiedz jest prosta: tablica nie moze byc wrapperem dla kolekcji.

--
Michal

[Jacek Czerwinski]

Michal Kleczek pisze:
> Jacek Czerwinski wrote:

>> Pytanie, które zredaguję inaczej: jeśli dostarczam OBA interfejsy, tzn
>> tablicę i do wyboru List //być może Collection, dzięki za
>> przypomnienie//, który zrobić wrapperem nad którym, którą strukturę
>> wybrać do wewnętrznej implementacji, bo ta oczywiście jest jedna.
>
> Odpowiedz jest prosta: tablica nie moze byc wrapperem dla kolekcji.

Przepisać te referencje nie problem gdyby trzeba ;)
nawiasem wbudowane konwersje (toArray itd) też przepisują. Waga obiektów
jest spora, długo żyją, algorytmy nie są krytyczne szybkościowo itd,
więc przepisania (np w konstruktorze) nie postzregam jako istotny koszt,
a nawet pikuś.

Pytanie o to "warto". Za czym są jakie argumenty za wnętzzrem takim lub
takim. Tablica ma stałą długość, inne zmienną, wiem.

[Krzysztof Wolny]

* Jacek Czerwinski wrote, W dniu 2010-01-05 11:13:
> Michal Kleczek pisze:
>> Jacek Czerwinski wrote:
>

>>> Pytanie, kt�re zredaguj� inaczej: je�li dostarczam OBA interfejsy, tzn
>>> tablic� i do wyboru List //by� mo�e Collection, dzi�ki za
>>> przypomnienie//, kt�ry zrobi� wrapperem nad kt�rym, kt�r� struktur�

>>> wybra� do wewn�trznej implementacji, bo ta oczywi�cie jest jedna.

>>
>> Odpowiedz jest prosta: tablica nie moze byc wrapperem dla kolekcji.
>

> Przepisaďż˝ te referencje nie problem gdyby trzeba ;)
> nawiasem wbudowane konwersje (toArray itd) te� przepisuj�. Waga obiekt�w
> jest spora, d�ugo �yj�, algorytmy nie s� krytyczne szybko�ciowo itd,
> wi�c przepisania (np w konstruktorze) nie postzregam jako istotny koszt,
> a nawet pikuďż˝.
>
> Pytanie o to "warto". Za czym s� jakie argumenty za wn�tzzrem takim lub
> takim. Tablica ma sta�� d�ugo��, inne zmienn�, wiem.

Zalezy od operacji jakie wykonujesz w 'wewnetrznej implementacji'. Jesli
to proste petle to daj tablice, mniej zajmuja pamieci chocby.

Ale jesli masz zlozone operacje, do ktorych moga sie przydac metody z
List/Collection (subList itp) to wez List/Collection.

--
Krzysztof Wolny

kkk....@gmail.com (replace 'kkk' with one 'k')

[Michal Kleczek]

Jacek Czerwinski wrote:

Jest roznica w semantyce pomiedzy:

Arrays.asList() i Collection.toArray()

W zaleznosci od tego, co twoj program robi - potrzebujesz czegos innego. Nie
ma ogolnych wytycznych.

--
Michal

[MZ]

Michal Kleczek pisze:

> Jest roznica w semantyce pomiedzy:
>
> Arrays.asList() i Collection.toArray()

jaka?

--
Pozdrawiam
Mateusz
http://na-jawie.blogspot.com

[Michal Kleczek]

MZ wrote:

> Michal Kleczek pisze:
>> Jest roznica w semantyce pomiedzy:
>>
>> Arrays.asList() i Collection.toArray()
>
> jaka?
>

Object[] originalArr = new Object[] {new Object(), new Object()};
List originalCol = new ArrayList(originalArr);

List targetCol = Arrays.asList(originalArr);
Object[] targetArr = originalCol.toArray();

System.out.println(originalArr[1]);
System.out.println(originalCol.get(1));

originalArr[1] = new Object();
originalCol.set(1, originalArr[1]);

System.out.println(originalArr[1]);
System.out.println(originalCol.get(1));

--
Michal

[Michal Kleczek]

MZ wrote:

> Michal Kleczek pisze:
>> Jest roznica w semantyce pomiedzy:
>>
>> Arrays.asList() i Collection.toArray()
>
> jaka?
>

Object[] originalArr = new Object[] {new Object(), new Object()};

List originalCol = new ArrayList(originalArr);

List targetCol = Arrays.asList(originalArr);
Object[] targetArr = originalCol.toArray();

System.out.println(originalArr[1]);
System.out.println(originalCol.get(1));

targetArr[1] = new Object();
targetCol.set(1, originalArr[1]);

System.out.println(targetArr[1]);
System.out.println(targetCol.get(1));

--
Michal

[Michal Kleczek]

MZ wrote:

> Michal Kleczek pisze:
>> Jest roznica w semantyce pomiedzy:
>>
>> Arrays.asList() i Collection.toArray()
>
> jaka?
>

Cholera, dwa razy mi sie zle kliknelo.
Jeszcze raz:

Object[] origArr = new Object[] {new Object()};
List origCol = new ArrayList(origArr);

List targetCol = Arrays.asList(origArr);
Object[] targetArr = origCol.toArray();

System.out.println(targetArr[0]);
System.out.println(targetCol.get(0));

origArr[0] = new Object();
origCol.set(0, origArr[0]);

System.out.println(targetArr[0]);
System.out.println(targetCol.get(0));

--
Michal

[Soltys]

Michal Kleczek pisze:

Nie wiem, z jakiem implementacji Javy korzystasz, ale
w Javie 5 i 6 ArrayList ma naste;puja;ce konstruktory:
- ArrayList()
- ArrayList(Collection c)
- ArrayList(int initialCapacity)

?

--
Soltys

"Free software is a matter of liberty not price"

[Michal Kleczek]

Soltys wrote:

Kod byl pisany w newsreaderze. Zmien na:

new ArrayList(Arrays.asList(origArr));

--
Michal

[ruf10]

On 06.01.2010 09:53, Michal Kleczek wrote:
> Soltys wrote:
[...]
> new ArrayList(Arrays.asList(origArr));

Błąd
Arrays.asList zwraca Arrays$ArrayList i efektywnie jest operacją przypisania
wywołanie konstruktora ArrayList spowoduje sklonowanie origArr

[Michal Kleczek]

ruf10 wrote:

> On 06.01.2010 09:53, Michal Kleczek wrote:
>> Soltys wrote:
> [...]
>> new ArrayList(Arrays.asList(origArr));
>
> Błąd
> Arrays.asList zwraca Arrays$ArrayList i efektywnie jest operacją
> przypisania

Ze co?

> wywołanie konstruktora ArrayList spowoduje sklonowanie origArr

Dokladnie o to mi chodzilo.

--
Michal

[ruf10]

On 06.01.2010 16:29, Michal Kleczek wrote:
> ruf10 wrote:
>
>> On 06.01.2010 09:53, Michal Kleczek wrote:
>>> Soltys wrote:
>> [...]
>>> new ArrayList(Arrays.asList(origArr));
>>
>> Błąd
>> Arrays.asList zwraca Arrays$ArrayList i efektywnie jest operacją
>> przypisania
>
> Ze co?

public class Arrays{

public static <T> List<T> asList(T... a) {
return new ArrayList<T>(a);
}

private static class ArrayList<E> extends AbstractList<E> {
ArrayList(E[] array) {
if (array==null)
throw new NullPointerException();
a = array;
^^^^^^^^^
}
}
}

Arrays.asList sprowadza się do operacji przypisania, czyli tablica nie jest kopiowana, w przeciwieństwie do
konstruktora java.util.ArrayList(Collection)

>> wywołanie konstruktora ArrayList spowoduje sklonowanie origArr
>
> Dokladnie o to mi chodzilo.

no to ok

[Michal Kleczek]

ruf10 wrote:

> On 06.01.2010 16:29, Michal Kleczek wrote:
>> ruf10 wrote:
>>
>>> On 06.01.2010 09:53, Michal Kleczek wrote:
>>>> Soltys wrote:
>>> [...]
>>>> new ArrayList(Arrays.asList(origArr));
>>>
>>> Błąd
>>> Arrays.asList zwraca Arrays$ArrayList i efektywnie jest operacją
>>> przypisania
>>
>> Ze co?
>
> public class Arrays{
>
> public static <T> List<T> asList(T... a) {
> return new ArrayList<T>(a);
> }
>
> private static class ArrayList<E> extends AbstractList<E> {
> ArrayList(E[] array) {
> if (array==null)
> throw new NullPointerException();
> a = array;
> ^^^^^^^^^
> }
> }
> }
>
> Arrays.asList sprowadza się do operacji przypisania, czyli tablica nie
> jest kopiowana, w przeciwieństwie do konstruktora
> java.util.ArrayList(Collection)

A, o to ci chodzi... Zeby to wiedziec wystarczy przeczytac dokumentacje
Arrays.asList():
"Returns a fixed-size list backed by the specified array. (Changes to the
returned list "write through" to the array."

--
Michal