Java: Czego mi brak: Operator warunkowy

[Lasu]

Witam!

A więc brakuje mi operatora który by działał jak '.' z małym wyjątkiem
jeśli nadrzędny obiekt byłby null-em, wówczas null byłby zawsze
zwracany. Było by to pozytywne gdy komuś nie chce się deklarować tony
niepotrzebnych zmiennych tylko po to, żeby zajrzeć co jest w środku.
W bardziej skomplikowanych przypadkach niż ten niżej często aby
uniknąć zagrożenia wynikającego z możliwości użycia nieodpowiedniego
pola jest konieczność wydzielania sztucznych bloków tylko po to alby
zmienne się nie walały po metodzie.


Przykład użycia:

public class Test {

public static class SomeHouse {
public MainEntry mainEntry;
}

public static class MainEntry {
public RealyRealyGoodLock realyRealyGoodLock;
}

public static class RealyRealyGoodLock {
public LockMode lockMode;
}

public static class LockMode {

}

/**
* Good and hard
*/
public static LockMode getLockModeStandard(SomeHouse someHouse) {
if (someHouse == null) { return null; }
MainEntry mainEntry = someHouse.mainEntry;
if (mainEntry == null) { return null; }
RealyRealyGoodLock rGoodLock = mainEntry.realyRealyGoodLock;
if (rGoodLock == null) { return null; }
return rGoodLock.lockMode;
}

/**
* Can case some efficiency problems if <code>null</code> occurs
really often.
*/
public static LockMode getLockModeBad(SomeHouse someHouse) {
try {
return someHouse.mainEntry.realyRealyGoodLock.lockMode;
} catch (NullPointerException e) {
return null;
}
}

/**
* This will do not work properly while changing from other thread
*/
public static LockMode getLockModeWorst(SomeHouse someHouse) {
if (someHouse == null) return null;
if (someHouse.mainEntry == null) return null;
if (someHouse.mainEntry.realyRealyGoodLock == null) return null;
return someHouse.mainEntry.realyRealyGoodLock.lockMode;
}

/**
* Would be better
*/
public static LockMode getLockModeSuggested(SomeHouse someHouse) {
return someHouse.?.mainEntry.?.realyRealyGoodLock.?.lockMode;
}

/**
* Would be better
*/
public static LockMode getLockModeSuggestedOther(SomeHouse
someHouse) {
LockMode lockMode
=someHouse.?.mainEntry.?.realyRealyGoodLock.?.lockMode;
if (lockMode==null){
// Do what u want
}
return lockMode;
}

/**
* Mixed case where we know that {@link
MainEntry#realyRealyGoodLock}
* is mandatory and should never happen for this field to be null.
*/
public static LockMode getLockModeMixed(SomeHouse someHouse) {
return someHouse.?.mainEntry.realyRealyGoodLock.?.lockMode;
}
}


to samo na PJug:
http://groups.google.com/group/polish-java-user-group/browse_thread/thread/29afc1d5e227a27c?hl=pl
Jaka jest wasza opinia ?
--
Pozdrowionka
Lasu <Marek Kozieł>

[Rafał Żukowski]

No cóż, nie tylko Tobie brakuje.

Twórcom języka Groovy też tego brakowało, dlatego wprowadzili:

Safe Navigation Operator :
 http://groovy.codehaus.org/Operators

Może powinieneś się się zainteresować Groovym, skoro lubisz takie bajery (ja też lubię).

pozdro.

[slawek sobotka]

Moja opinia jest taka, ze powyzszy problem nie ma prawa wystepowac w
przypadku programowania zgodnie z zasadami OO.
Łańcuszki typu a.b.c.d lub nawet a.getB().getC().getD() są nazywane
"train wreck" i są wbrew enkapsulacji poniewaz literalnie wybebeszasz
klasę z jej wnętrznosci - uzywając getterow robisz to jedynie w sposb
bardziej sterylny (cos jak białe rekawiczki) ale w dalszym ciagu jest
to podejscie charketrystyczne dla struktur danych w jezykach
proceduralnych :P

[Lasu]

Ehh!
Jak dla ciebie mogą być tam metody.
Użyłem pól żeby nie zaciemniać obrazu.

[slawek sobotka]

Jakie metody? Chodzi o gettery?
Jezeli tak, to wciaz obstaje przy tym com napisal: gettery NIC nie
zmeniają, jest to tylko bardziej kuriozalny sposob na złamanie zasady
enkapsulacji:)

[Irek Matysiewicz]

Java została pomyślana jako prosty język. Sytuacje o których piszesz
zdarzają się (przynajmniej mi) bardzo rzadko, więc nie ma sensu
zaśmiecać Javy kolejnym operatorem, który i tak byłby rzadko używany.

Taki operator jest w Groovym (alternatywny język działający na JVM).
Jest tam operator ?. który działa dokładnie jak piszesz. Może powinieneś
zacząć pisać w Groovym?

Lepszą alternatywą może być użycie wzorca NullObject: zamiast null-i
zwracasz specjalne implementacje które nic nie robią. Ogólnie pozwoli to
zaoszczędzić wiele if-ów:
if(coś == null) {coś.zróbcoś();} else {...}
stanie się po prostu:
coś.zróbcoś()

Ogólnie tasiemce w stylu:

someHouse.mainEntry.realyRealyGoodLock.lockMode

mogą też świadczyć o braku enkapsulacji w klasach. Taki kod będzie
toporny do zmian. Zobacz czy czegoś tam się nie da zaenkapsulować.

Lasu pisze:

[Lasu]

On 8 Gru, 16:21, Irek Matysiewicz <iir...@gmail.com> wrote:
> Ogólnie tasiemce w stylu:
>
>     someHouse.mainEntry.realyRealyGoodLock.lockMode
>
> mogą też świadczyć o braku enkapsulacji w klasach. Taki kod będzie
> toporny do zmian. Zobacz czy czegoś tam się nie da zaenkapsulować.

Mogą ale nie muszom!

To czy to jest objaw braku enkapsulacji czy nie zależy od specyfiki
problemu.
Jeśli problem jest 'rodzaju' grafu / drzewa to nie ma co enkapsulować,
poza warstwą dostępu.

[Lasu]

> if(coś == null) {coś.zróbcoś();} else {...}

Umkło mi.
Ten 'wzorzec' nie działa w przypadku aplikacji wielo-wątkowych, gdy
występuje możliwość zmiany stanu.
Chyba że ktoś pisze jednowątkowe aplikacje, wtedy jest ok.

Jak już pisałem, ta zasada nie zawsze ma zastosowanie.
XML ?

[Irek Matysiewicz]

Lasu pisze:

>> if(coś == null) {coś.zróbcoś();} else {...}
>>
>
> Umkło mi.
> Ten 'wzorzec' nie działa w przypadku aplikacji wielo-wątkowych, gdy
> występuje możliwość zmiany stanu.
> Chyba że ktoś pisze jednowątkowe aplikacje, wtedy jest ok.
>
>
>

To już kwestia synchronizacji. Jak robisz:
cośtam1.cośtam2.cośtam3.cośtam4, to w aplikacji wielowątkowej też
wypadałoby wszystkie cośtamy które mogą się w międzyczasie zmienić wziąć
w 'synchronized' przed dostępem do ich wnętrza. Zapewne operator ?. tego
synchronized nie daje i wszystko lipa.

[Lasu]

On 8 Gru, 16:50, Irek Matysiewicz <iir...@gmail.com> wrote:
> To już kwestia synchronizacji. Jak robisz:
> cośtam1.cośtam2.cośtam3.cośtam4, to w aplikacji wielowątkowej też
> wypadałoby wszystkie cośtamy które mogą się w międzyczasie zmienić wziąć
> w 'synchronized' przed dostępem do ich wnętrza. Zapewne operator ?. tego
> synchronized nie daje i wszystko lipa.

To tylko kwestia implementacji operatora.
Są ogólnie dwie metody zaimplementowanie takowego, dla jednego to nie
jest problemem dla drugiego jest.

Osobiście nie przepadam za synchronized o ile to nie jest konieczne.
Ale co kto woli.

[Rafał Żukowski]

W dniu 8 grudnia 2008 16:57 użytkownik Lasu <develo...@gmail.com> napisał:

On 8 Gru, 16:50, Irek Matysiewicz <iir...@gmail.com> wrote:
> To już kwestia synchronizacji. Jak robisz:
> cośtam1.cośtam2.cośtam3.cośtam4, to w aplikacji wielowątkowej też
> wypadałoby wszystkie cośtamy które mogą się w międzyczasie zmienić wziąć
> w 'synchronized' przed dostępem do ich wnętrza. Zapewne operator ?. tego
> synchronized nie daje i wszystko lipa.

To tylko kwestia implementacji operatora.
Są ogólnie dwie metody zaimplementowanie takowego, dla jednego to nie
jest problemem dla drugiego jest.

Tym razem  to już strzeliłeś sobie samobója. To nie jest "kwestia implementacji operatora". Operator to metoda o nieco innej składni, przyjmuje 1,2 albo 3 argumenty i coś tam zwraca (akurat w przypadku tego operatora ta definicja jest naciągana)...

W przypadku aplikacji wielowątkowej (ze zmieniającymi się stanami interesujących nas obiektów), nie wyobrażam sobie w pełni poprawnego działania łańcuszka cośtam1.cośtam2.cośtam3.cośtam4. Nie wiem jak chcesz ten operator zaimplementować. W przypadku aplikacji wielowątkowej, TYM BARDZIEJ należy zastosować lepszą enkapsulację jak proponowali koledzy i zadbać o synchronizację...

pozdro.

[Lasu]

On 8 Gru, 19:15, "Rafał Żukowski" <rzu...@gmail.com> wrote:

> W dniu 8 grudnia 2008 16:57 użytkownik Lasu <develop4l...@gmail.com>napisał:
> Tym razem  to już strzeliłeś sobie samobója. To nie jest "kwestia
> implementacji operatora". Operator to metoda o nieco innej składni,
> przyjmuje 1,2 albo 3 argumenty i coś tam zwraca (akurat w przypadku tego
> operatora ta definicja jest naciągana)...
>
> W przypadku aplikacji wielowątkowej (ze zmieniającymi się stanami
> interesujących nas obiektów), nie wyobrażam sobie w pełni poprawnego
> działania łańcuszka cośtam1.cośtam2.cośtam3.cośtam4. Nie wiem jak chcesz ten
> operator zaimplementować. W przypadku aplikacji wielowątkowej, TYM BARDZIEJ
> należy zastosować lepszą enkapsulację jak proponowali koledzy i zadbać o
> synchronizację...
>
> pozdro.

I tak i nie.
To pytanie tak naprawdę miało się nijak do problemu.
Spróbuje lakonicznie objaśnić w czym rzecz.

a.?.b.?.c()

sposób zaimplementowania A. :
1. if (a==null) return null;
3. b=a.b();
4. if (b==null) return null;
6. return b.c();


numeracja jest celowa.
2 i 5. modlimy się żeby nikt nie zmienił czegoś wewnątrz z innego
wątku

sposób zaimplementowania B. :
1. la=a;
2. if (la==null) return null;
3. lb =la.b;
4. if (lb==null) return null;
5. return lb.c();

sama synchronizacja to zupełnie inna sprawa i nie ma tu znaczenia
(przynajmniej dla większości)
i konstrukcja:
if (a!=null){}
else{}
mogła by zwrócić NullPointerException nawet jeśli get-ery były by
synchronizowane.

dopiero
ClassA la;
if ((la=a)!=null){
la. ...
}
else{}
zabezpiecza przed wyjątkiem.

Jak dla mnie konstrukcja podana przez Irka jest bez wartościowa, bo w
zasadzie musimy pisać w każdej metodzie która może używać w/w. że
istnieje możliwość wyjątku.
I może to jest też kontekst w jakim należy rozważać zaletę tego
operatora.
bo { if (a.b==null) } jest bez sensu na dłuższa metę (nie twierdzę, że
zawsze).


Ze Sławkiem też się mogę zgodzić.
Użyteczność operatora jest podyktowana (wysoką) ziarnistością kodu,
która to cecha zależy od problemu a nie od OO. i to raczej OO mówi że
jak masz:
Człowiek -> Ręka(l/r) -> Palec()
a nie
Człowiek.getPalecWskULewejRęki();

A nie zawsze nas interesuje czy ktoś nie ma ma palca bo nie ma, czy
nie ma bo nie ma ręki.
Bez sensu jest dla mnie sprawdzanie powodu (nie posiadania palca).

Pozdrowionka !

[Slawek Sobotka]

> Ze Sławkiem też się mogę zgodzić.
> Użyteczność operatora jest podyktowana (wysoką) ziarnistością kodu,
> która to cecha zależy od problemu a nie od OO.

No niestety ja się nie zgodzę z Twoją zgodą ze mną:P
Nie o to mi chodzilo, ale po kolei:

Na wstępie rys historyczny: drzewiej w turbo pascalu programowało się
na przykład na rekordach: http://turbopascal.helion.pl/r-14.htm
Tworzono wowczas zagniezdzane struktury, na przyklad czlowiek, ktory
sklada się z rąk a ręce skladają się z palcow. Na tych strukturach
operowaly procedury. Z czasem ludzie zrozumieli, ze powoduje to ból
porownywalny do tego, ktory wystepuje podczas otwierania sobie
parasola w tej no... w nosie. Ból, ktory pojawia sie w przypadku
zmiany naszej złożonej struktury danych. Albo inaczej - zmiana nie
jest mozliwa bo rozsypała by cały program.

Pozniej nadejszla wiekopomna chwila gdy ludzie zrozumieli, ze co
prawda zmian nie da sie uniknac, ale mozna minimalizowac
prawdopodbienstwo wystapienia bólu przy zmianach sotojąc arcy-chytry
trik: ukrywając potencjalne miejsca narazone na zmiany (hehe kto by
sie spodziewal tak chytrego triku). Jest to enkapsulacja będąca
podsawowym paradymatem programowania obiektowego:
http://pl.wikipedia.org/wiki/Programowanie_obiektowe

Masz rację piszac

>A nie zawsze nas interesuje czy ktoś nie ma ma palca bo nie ma, czy
>nie ma bo nie ma ręki.
>Bez sensu jest dla mnie sprawdzanie powodu (nie posiadania palca).

ideologicznie kombinujesz w dobrym kierunku, jest to wlasnie cos z OO,
ale na poziomie implementacji nie tak

>Człowiek -> Ręka(l/r) -> Palec()

ani nie tak
>Człowiek.getPalecWskULewejRęki();

wiec jak?
zalezy co chcesz zrobic, ale podejrzewam, ze cos takiego:
czlowiek.przyjmij(artefakt);
w tym wypadku nie interesuje mnie czy czlowiek wezmie go do reki, do
ust;) do kieszeni czy do plecaka. Jest to jego osobista sprawa jak
sobie poradzi z odpowiedzionoscią przyjecia czegos - ukrywa przed nami
zarowno swą budowę ciała jak i inne atrybuty. Ona ma cos wziac i
ewentualnie zglosic weto, ze na przyklad nie moze ponieaz nie ma
miejsca albo jest zbyt to ciezkie.
Co dzieki temu osiagamy? Wlasnie tą otwartosc na rozbudowę i
zamniętosc na zmiany. Byc moze poki co przewidujesz ze czlowiek bierze
do rąk ale z czasem szef kaze Ci doimplementowac plecak;P Ile
procedurek bedzie wowczas do przepisania i ponownego przetestowania?

Warto zwrocic uwage na odwrocenie myslenia: mamy to do czynienia z
obiektem obdarzonym odpowiedzianosciami/zdolnosciami a nie z bezmyslną
strukturą danych na ktorej operują zewnetrzne procedury.

[Michał Stolarczyk]

Zrobię mały offtopic, który nic nie wniesie do dyskusji ale...
W frameworku Tapestry 5 w warstwie widoku też jest operator warunkowy,
który działa jak opisał to Lasu.
Koniec ;)

[G.]

Słyszałem, że Perl to bardzo dobry język programowania.

Z drugiej strony - widząc ile Java ma niedoskonałości, czuję, że
niedługo doczekamy się nowego, udoskonalonego języka.

G.

[Lasu]

On 8 Gru, 21:37, Slawek Sobotka <sso...@gmail.com> wrote:
>czlowiek.przyjmij(artefakt);

I właśnie o to mi chodzi.
Na zewnątrz jak najbardziej tak to powinno wyglądać.
Ale w środku chciałbym móc sobie ułatwić sprawę.
Napisać to głupie
this.Ręka(l/r).?.Palec()
w ciągu kilku sec a jak będę miał coś więcej to napisać więcej, a nie
kaskada if-ów.

Co jak co ale nie możesz zapomnieć, że nie rzadko pod 'ładnym'
interfejsem leżą zwykłe 'paskalowe' 'struktury' bo są one proste
(przynajmniej na początku).
Jeśli więc będą one łatwiejsze do operowania gwarantuje Ci, że
programista będzie miał więcej czasu na myślenie o OO.

[slawek sobotka]

> Na zewnątrz jak najbardziej tak to powinno wyglądać.
> Ale w środku chciałbym móc sobie ułatwić sprawę.
> Napisać to głupie
> this.Ręka(l/r).?.Palec()
> w ciągu kilku sec a jak będę miał coś więcej to napisać więcej, a nie
> kaskada if-ów.
>
> Co jak co ale nie możesz zapomnieć, że nie rzadko pod 'ładnym'
> interfejsem leżą zwykłe 'paskalowe' 'struktury' bo są one proste
> (przynajmniej na początku).
> Jeśli więc będą one łatwiejsze do operowania gwarantuje Ci, że
> programista będzie miał więcej czasu na myślenie o OO.

Jest dokladnie odwrotnie.
Wewnętrzna struktura jest jak fraktal;)
Obiekty agregują inne obiekty...
zamiast
this.Ręka(l/r).?.Palec()
lepiej analogicznie jak wyzej:
this.reka.złap(coś) - ręko, nie wazne jak to złapiesz, jezeli masz
obciete paluchy to zglos veto

odwrotnie tez w tym sensie, ze na samej gorze daje sie zazyczaj
interfejs w postaci procedury - bo to latwiej zrozumiec i przyda sie
biznesowi do SOA ;P

//=============
z mojej strony pass

[Lasu]

Ni huhu cię nie czaje.
Co za różnica czy na pisze
i++;
czy
i= i+1;
dla OO
dla mnie bez sensu

a pisanie czegoś takiego:

public Coś
parseXML()
{
operacja 1
operacja 2
operacja 3
Z =z
{
B b= a.b;
if (b!=null){
C c= c.c;
if(c!=null){
D d=c.d;
if (d!=null){
E e = e.e{
// I tak do z
}
}
}
}
return (z==null?null:z.getCos());
}

}

to totalna paranoja
zamiast
a.?.b.?.c.?.d.?.e.?.f.?.g.?. ... z.?.getCos()
Coś się zmieni i poprawiać ten stos if-ów.

XML to sztandarowy przykład. Często dostajemy wszystkie dane nawet
jeśli 1% nas interesuje.

Poza tym:

Co jak co ale coś mi tu nie gra, raz piszecie, że nie można
wszystkiego zwalać na jeden 'god' obiekt a jak chcę oddelegować
odpowiedzialności do innych obiektów to zaczynają się krzyki w stylu:
'Na stos, przeciw OO bluźni!' o.O
jak nie pokaże palcem to się nikt nie domyśli -.-
ObiektA.?.odpowiedzialnośćA.?.podOdpowiedzialnośćA(wykonaj);
Nie wiem jak chcesz/chcecie mnie przekonać nagle, że wszystkie
odpowiedzialności powinny być pod jednym obiektem.

Mam nadzieje, że nikt się nie obrazi ale zwyczajnie nie mogę się
zgodzić, bo nie widzę jasnych powodów.

[slawek sobotka]

> Co jak co ale coś mi tu nie gra, raz piszecie, że nie można
> wszystkiego zwalać na jeden 'god' obiekt a jak chcę oddelegować
> odpowiedzialności do innych obiektów to zaczynają się krzyki w stylu:
> 'Na stos, przeciw OO bluźni!' o.O
> jak nie pokaże palcem to się nikt nie domyśli -.-
> ObiektA.?.odpowiedzialnośćA.?.podOdpowiedzialnośćA(wykonaj);
> Nie wiem jak chcesz/chcecie mnie przekonać nagle, że wszystkie
> odpowiedzialności powinny być pod jednym obiektem.

Obiecalem spasowac, ale jeszcze sprobuje...
W poczuciu obowiązku popelnilem nawet na szybko posta
http://art-of-software.blogspot.com/2008/12/flaczki-kod-obiektowy-zawsze-smaczny-i.html

1. Agregacja i delegacja to nie god-object - zagregowane obiekty z
dobrze wyspecyfikowaną i spojną odpowiedzialnoscią sa reuzywalne. W
dobrym projekcie obiekt stojacy wyzej w agregacie nie ma wszechmocnej
odpowiedzialnosci bo jego kontekst jest z wyzszego poziomu abstrakcji.
2. XML to akurat nie jest sztandarowy przyklad OO a problemow
proceduralnych. Masz paczke danych (ktora z definicji i idei XMLa nie
moze miec odpowiedzialnosci) i ją obrabiasz jakąś obrabiarką. Trudno
czasem w zyciu trzeba poobrabiac jakies dane - taka praca, ale to nie
całe uniwersum programowania.

[Lasu]

W przypadku XML posiadanie pod-elementów jest odpowiedzialnością.

On 8 Gru, 23:57, "slawek sobotka" <sso...@gmail.com> wrote:
>Trudno czasem w zyciu trzeba poobrabiac jakieś dane.
Ty raczej nie musisz ale inni mniej bądz wiecej 'tak'.

>taka praca, ale to nie całe uniwersum programowania.

Fakt ale język to coś więcej, niż narzędzie do ładnego rysowania
diagramów UML.
Nie rozumiem czemu ci tak przeszkadza, że ktoś kto przetwarza grafy/
XML-e czy inne cuda na kiju bylby miał łatwiejsze życie skoro to by
cię nic nie kosztowało.

> > Co jak co ale coś mi tu nie gra, raz piszecie, że nie można
> > wszystkiego zwalać na jeden 'god' obiekt a jak chcę oddelegować
> > odpowiedzialności do innych obiektów to zaczynają się krzyki w stylu:
> > 'Na stos, przeciw OO bluźni!' o.O
> > jak nie pokaże palcem to się nikt nie domyśli -.-
> > ObiektA.?.odpowiedzialnośćA.?.podOdpowiedzialnośćA(wykonaj);
> > Nie wiem jak chcesz/chcecie mnie przekonać nagle, że wszystkie
> > odpowiedzialności powinny być pod jednym obiektem.
>
> Obiecalem spasowac, ale jeszcze sprobuje...

> W poczuciu obowiązku popelnilem nawet na szybko postahttp://art-of-software.blogspot.com/2008/12/flaczki-kod-obiektowy-zaw...

[Rafał L.]

On 8 Gru, 23:57, "slawek sobotka" <sso...@gmail.com> wrote:

> Obiecalem spasowac, ale jeszcze sprobuje...

A propos tematu, wychodzi na to, że wielu z nas nie jest do końca
świadomym jak powinien wyglądać nasz obiektowy kod mimo, że wszyscy
dumnie twierdzimy, że programujemy zgodnie z OOP.
A tak się dziwnie składa, że w puli potencjalnych prelekcji znajduje
się Twój już dawno wrzucony temat: "Praktyczne aspekty wykorzystania
wzorców architektonicznych i projektowych". ;)
Myślę, że to dobry temat do odświeżenia dla tych co byli na lubelskich
dniach informatyki i bardzo pożądany przez tych którzy być tam nie
mogli (np. dla mnie).


Co Ty na to by przedstawić ten temat w styczniu?
Wychodzi na to, że przez zawirowania z salą i natłok obowiązków u
Piotrka w grudniu zostaniemy bez prelekcji.
Fajnie jakby się udało odrobić ten czas i ze zdwojoną siłą (czytaj 2
prelekcje) rozpocząć nowy rok.
Jakbyś tylko miał czas i ochotę. Ja bym chętnie skorzystał. Myślę, że
inni też, a i Lasu z pewnością zagwarantuje Ci długą dyskusję w
trakcie i po prelekcji. :)

Ps. Wtedy co prawda stałbyś się już monopolistą jeśli chodzi o ilość
wygłoszonych prelekcji, ale co tam. :)

[Maciej Zubala]

@Lasu: jeśli Sławek nie jest w satnie Cię przekonać do oddzielania interfejsu od implementacji, to może zrobi to niejaki Allen Holub, który napisał na ten temat bardzo dobry artykuł pt. "Why getters and setters are evil":

http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html

Artykuł ten porusza jeszcze jedną ważną kwestię, o której tutaj nie było mowy, a mianowicie jak tworzyć interfejs użytkownika nie naruszając enkapsulacji - przecież przeważająca większość programów obiektowych musi mieć GUI.
Po przeczytaniu dowiecie się, jak przedstawić na UI flaki wspomnianego tutaj człowieka bez wyciągania ich na zewnątrz ;)

[Slawek Sobotka]

>Nie rozumiem czemu ci tak przeszkadza, że ktoś kto przetwarza grafy/
>XML-e czy inne cuda na kiju bylby miał łatwiejsze życie skoro to by
>cię nic nie kosztowało.

Sęk w tym, ze to własnie kosztuje - masakrycznie. Ty tego nie musisz
liczyć, ale ktos przepłaca realne pieniadze za utrzymanie kodu, ktory
broni się rekami, nogami i getterami przed utrzymaniem i
nieuniknionymi modyfikacjami. Wersja 2.0 powstaje jak krew z nosa a
wersja 3.0 jest niemozliwa z uwagi na zamulenie kodu:)


Irek - podales rozsądny argument: prawdopodobienstwo. Struktury, ktore
na tak podstawowym poziomie są nullowe są podejrzane.

Rafał - nie jestem zadowolony z tej prezentacji i musze ją zmienic -
kwestia czasu:/

[Lasu]

On 9 Gru, 09:32, "Maciej Zubala" <maciej.zub...@gmail.com> wrote:
> @Lasu: jeśli Sławek nie jest w satnie Cię przekonać do oddzielania
> interfejsu od implementacji, to może zrobi to niejaki Allen Holub, który
> napisał na ten temat bardzo dobry artykuł pt. "Why getters and setters are
> evil":
>
> http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html

Zgadzam się w 100% z artykułem.
Ale nadal uważam, że ten operator powinien istnieć.
<b>Równie dobrze możemy powiedzieć, że w idealnym świecie nie ma głodu
więc nie ma co z nim walczyć.
A niech poumierają głodni / pewnie są głodni bo byli grzesznikami.
Buhaha.</b>

o.O

[Lasu]

Poszło na:
http://blogs.sun.com/darcy/entry/small_language_changes_jdk_7
Zobaczymy czy coś z tego wyjdzie.