🚀 go-pugleaf

"Przemek Pokrywka" <adres@zastrzezony.com> wrote:

> Osoby zaznajomione z Javą znają pojęcie tzw. "settera" - metody służącej 
> do ustawiania wartości jakiegoś atrybutu. Metody te standardowo nie 
> zwracają żadnej wartości.
>
> Co Państwo myślą o praktyce zwracania przez takie metody obiektu 
> deklarującej je klasy? Tzn.

Nie jestem Javowcem, ale mysle ze to bardzo zla praktyka.
Bez wzgledu na jezyk programowania.

AK

Użytkownik "Przemek Pokrywka" napisał:
> [...]
> Co Państwo myślą o praktyce zwracania przez takie metody obiektu
> deklarującej je klasy? [...]

W bibliotekach Javy metody setX() zwracaja void, wiec dla spojnosci lepiej
sie tego trzymac.

Adam

Adam Karpierz wrote:
> "Przemek Pokrywka" <adres@zastrzezony.com> wrote:

<ciah>

> Nie jestem Javowcem, ale mysle ze to bardzo zla praktyka.
> Bez wzgledu na jezyk programowania.

Wrecz przeciwnie, bywa ze to bardzo dobra praktyka, taka konstrukcje 
wykozystuje sie do twozenia tzw. 'fluent interfaces' 
(http://martinfowler.com/bliki/FluentInterface.html), dobrym przykladem 
wykozystania tej techniki sa konfiguracje w frameworku Hibernate.

-- 
a1 (Bartek Janusz) arcone1 gmail com

Przemek Pokrywka wrote:

<ciah>

> Co Państwo myślą o praktyce zwracania przez takie metody obiektu 
> deklarującej je klasy? Tzn.
> 
> public AnObject setAttribute(AttributeType desiredAttributeValue) {
>     attribute = desiredAttributeValue;
>     return this;
> }

Tego typu konstrukcje to tzw. 'fluent interfaces'. Tutaj mozna troche o 
tym przeczytac: http://martinfowler.com/bliki/FluentInterface.html)
-- 
a1 (Bartek Janusz) arcone1 gmail com

Przemek Pokrywka napisał(a):
> Witam,
> 
> Osoby zaznajomione z Javą znają pojęcie tzw. "settera" - metody służącej
> do ustawiania wartości jakiegoś atrybutu. Metody te standardowo nie
> zwracają żadnej wartości.
> 
> Co Państwo myślą o praktyce zwracania przez takie metody obiektu
> deklarującej je klasy? Tzn.
> 
> public AnObject setAttribute(AttributeType desiredAttributeValue) {
>     attribute = desiredAttributeValue;
>     return this;
> }
> 

troche to dziwna konstrukcja zwłaszcza, ze ta metoda nie jest statyczna
a ustawiajac cos setterem na obiekcie w efekcie zmieniasz ten obiekt
wiec po co go zwracac ?

-- 
Pozdrawiam,
Marcin Łućko
http:\\www.croofec.net

Użytkownik "croofec" <spam@wytnij.croofec.net> napisał w wiadomości
news:e660l7$kgd$1@opal.icpnet.pl...
> Przemek Pokrywka napisał(a):
>
> troche to dziwna konstrukcja zwłaszcza, ze ta metoda nie jest statyczna
> a ustawiajac cos setterem na obiekcie w efekcie zmieniasz ten obiekt
> wiec po co go zwracac ?
>

o.setX(x).setY(y).setZ(z);

Adam

Przemek Pokrywka wrote:

> Co Państwo myślą o praktyce zwracania przez takie metody obiektu 
> deklarującej je klasy? Tzn.

Jeśli praktyka owa ma na celu 'method chaining', czyli zbudowanie 
'fluent interfaces', to ma sens. W przeciwny przypadku jest IMHO tylko 
zaciemniaczem kodu.

Ciekawy jest natomiast ten RFE:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6373386

Mnie, z przedstawionych tam, najbardziej przekonuje pomysł z 
traktowaniem wszystkich metod obiektu zwracających 'void', jak 
zwracających 'this'. Propozycja z jawnym 'this' w deklaracji mniej mi 
już odpowiada, sens jednak ma, jeśli istnieją jakieś przeciwwskazania 
dla propozycji wcześniejszej (których akurat, być może chwilowo, nie 
dostrzegam...).


piotr

"Adam Przybylek" <adampap@panda.bg.univ.gda.pl> wrote:

> o.setX(x).setY(y).setZ(z);

No wlasnie.
To jest ta tragedia.

AK

Adam Karpierz wrote:

<ciah>

>>o.setX(x).setY(y).setZ(z);
> 
> No wlasnie.
> To jest ta tragedia.

Tragedia bo...? osobiscie nie widze zadnych przeciwskazan, a dobrze 
skonstruowany fluent interface moze byc bardzo wygodny w uzyciu.

-- 
a1 (Bartek Janusz) arcone1 gmail com

"a1" <a1@no.spam> wrote in message news:e66dmr$q62$1@inews.gazeta.pl...

> Tragedia bo...? osobiscie nie widze zadnych przeciwskazan,

1. Wieksza bledogennosc - i to bledogennosc trudna niekiedy
     do wykrycia.
2. Nie widac "na rzecz czego"...
     W celu upewniania koneiczne siegniecie do definicji klasy
3. Mozliwe ukryte neichciane tworzenie (i usuwanie) obiektow
    tymczasowych (np w przypadku C++).
    Moze to powodowac paskudne efekty uboczne
..

> a dobrze skonstruowany fluent interface moze byc bardzo wygodny w uzyciu.

Nie widze wiekszej wygody od kasycznego zapisu.

o.setX(x);
o.setY(y);
o.setZ(z);

AK

Adam Karpierz wrote:
> "a1" <a1@no.spam> wrote in message news:e66dmr$q62$1@inews.gazeta.pl...
> 
> 
>>Tragedia bo...? osobiscie nie widze zadnych przeciwskazan,
> 
> 
> 1. Wieksza bledogennosc - i to bledogennosc trudna niekiedy
>      do wykrycia.
Błedogennosc? Bo musze mniej kodu napisac?

> 2. Nie widac "na rzecz czego"...
>      W celu upewniania koneiczne siegniecie do definicji klasy
Mowimy o dobrze skonstruowany fluent interface, wtedy tak naprawde 
zyskujemy na czytelnosci, oczywiscie mozna napisac to w taki sposob ze 
nie bedzie wiadomo o co chodzi, ale to tyczy sie dowolnego kodu.

> 3. Mozliwe ukryte neichciane tworzenie (i usuwanie) obiektow
>     tymczasowych (np w przypadku C++).
>     Moze to powodowac paskudne efekty uboczne
W c++ to wogole wszystko moze powodowac paskudne efekty uboczne.

> Nie widze wiekszej wygody od kasycznego zapisu.
> 
> o.setX(x);
> o.setY(y);
> o.setZ(z);

A tu:

	Order o1 = new Order();
        	customer.addOrder(o1);
         OrderLine line1 = new OrderLine(6, Product.find("TAL"));
         o1.addLine(line1);
         OrderLine line2 = new OrderLine(5, Product.find("HPK"));
         o1.addLine(line2);
         OrderLine line3 = new OrderLine(3, Product.find("LGV"));
         o1.addLine(line3);
         line2.setSkippable(true);
         o1.setRush(true);

vs.

         customer.newOrder()
                 .with(6, "TAL")
                 .with(5, "HPK").skippable()
                 .with(3, "LGV")
                 .priorityRush();

Bo jednak wersja duga wydaje mi sie jakby czytelniejsza. Zreszta cala ta 
idea 'metod chaining' pochodzi jednak ze znanej z roznych jezykow 
koncepcji cascade expression.

-- 
a1 (Bartek Janusz) arcone1 gmail com

Michal Przybylek wrote:

> Bo cholernie sie czyta.
Dobrze zrobiony czyta sie dobrze.

> Ten "fluent interface" to dirty hack na brak w Javie odpowiedniego
> mechanizmu powzalajacego na zlapanie obiektu do kontekstu.
Tak, to efekt braku cascade expressions, z czym sie zgadzam, ale 
kozystalem z kilku tego typu API (np. Hibernate, ale nie tylko) i, o ile 
byly dobrze zaprojektowane, to kozystalo sie z wygodniej niz z 
'klasycznych'.

-- 
a1 (Bartek Janusz) arcone1 gmail com

"a1" <a1@no.spam> wrote:

> >>o.setX(x).setY(y).setZ(z);
> >
> > No wlasnie.
> > To jest ta tragedia.
>
> Tragedia bo...?

Bo cholernie sie czyta.

Ja mam w ogole trudnosci z parsowaniem zlozonych wyrazen, a takie
konstrukcje wprowadzaja jeszcze dodatkowe "pieterko".

Ten "fluent interface" to dirty hack na brak w Javie odpowiedniego
mechanizmu powzalajacego na zlapanie obiektu do kontekstu.


mp

Witam

a1 wrote:

> Order o1 = new Order();
>         customer.addOrder(o1);
>          OrderLine line1 = new OrderLine(6, Product.find("TAL"));
>          o1.addLine(line1);
>          OrderLine line2 = new OrderLine(5, Product.find("HPK"));
>          o1.addLine(line2);
>          OrderLine line3 = new OrderLine(3, Product.find("LGV"));
>          o1.addLine(line3);
>          line2.setSkippable(true);
>          o1.setRush(true);
> 
> vs.
> 
>          customer.newOrder()
>                  .with(6, "TAL")
>                  .with(5, "HPK").skippable()
>                  .with(3, "LGV")
>                  .priorityRush();

To jest tendencyjna konstrukcja. Bo w wersji drugiej jakoś nie widać metody
Product.find, nie ma też powiedziane że są tworżone nowe obiekty co widać w
pierwszej wersji. A druga może sugerować tylko podmianę wartości.
Przedstawiłeś kawałek kodu, bez pokazania jego faktycznej implementacji, bo
Stosując sugestie Adama Karpierza powinieneś przeparafrazować swój kod na
taki:

        o1 = customer.newOrder()
        o1.with(6, "TAL");
        o1.with(5, "HPK");
        o1.get("HPK").skippable(); //ewentualnie to jeszcze rozbić na 2
        o1.with(3, "LGV");
        o1.get("LGV").priorityRush(); //ewentualnie to jeszcze rozbić na 2



Pozdrawiam.

-- 

|\/\/|   Seweryn Habdank-Wojewódzki
`\/\/   

"a1" <a1@no.spam> wrote in message Adam Karpierz wrote:

>> 1. Wieksza bledogennosc - i to bledogennosc trudna niekiedy
>>      do wykrycia.
> Błedogennosc? Bo musze mniej kodu napisac?

Dokaldnie tak, bveledogennosc . W dodatku bledy paskudne do wykrycia

class thir
      obj setZ(int X);

...

class other
      other setX(int val);
      other setY(int val);
      other setZ(int val);


      other other::setX(int val)
           ...
           return this

      other other::setY(int val)
           ...
           return thir

      other other::setZ(int val)
           ...
           return this



other o = new other();
o.setX(x).setY(y).setZ(z);

Kompiluje sie, dzial , miodzio!
Tylko robi nie to co trzeba.. :(

>> 2. Nie widac "na rzecz czego"...
>>      W celu upewniania koneiczne siegniecie do definicji klasy
> Mowimy o dobrze skonstruowany fluent interface, wtedy tak naprawde 
> zyskujemy na czytelnosci, oczywiscie mozna napisac to w taki sposob ze nie 
> bedzie wiadomo o co chodzi, ale to tyczy sie dowolnego kodu.

Tak, dowolnego
Kazdy dowolony kod zawiara ze swej natury dowolna ilosc bledow

>> 3. Mozliwe ukryte neichciane tworzenie (i usuwanie) obiektow
>>     tymczasowych (np w przypadku C++).
>>     Moze to powodowac paskudne efekty uboczne
> W c++ to wogole wszystko moze powodowac paskudne efekty uboczne.

W kazdym jezyku.
W Javie tez.

>> Nie widze wiekszej wygody od kasycznego zapisu.
>>
>> o.setX(x);
>> o.setY(y);
>> o.setZ(z);
>
> A tu:
>
> Order o1 = new Order();
>        customer.addOrder(o1);
>         OrderLine line1 = new OrderLine(6, Product.find("TAL"));
>         o1.addLine(line1);
>         OrderLine line2 = new OrderLine(5, Product.find("HPK"));
>         o1.addLine(line2);
>         OrderLine line3 = new OrderLine(3, Product.find("LGV"));
>         o1.addLine(line3);
>         line2.setSkippable(true);
>         o1.setRush(true);

Krotko bo nie mam czasu na jalowosc.
Traktujemy  sie powaznie ?

Order o = new Order();
o.with(6, "TAL");
o.with(5, "HPK")
o..skippable();
o.with(3, "LGV");
o.priorityRush();

a w niektoryc jezykach (chociaz srednio lubie taki podejscie
wylacznie w sensei synktatycznym).

with o
   .with(6, "TAL");
   .with(5, "HPK").skippable();
   .with(3, "LGV");
   .priorityRush();
.
> vs.
>
>         customer.newOrder()
>                 .with(6, "TAL")
>                 .with(5, "HPK").skippable()
>                 .with(3, "LGV")
>                 .priorityRush();
>
> Bo jednak wersja duga wydaje mi sie jakby czytelniejsza. Zreszta cala ta 
> idea 'metod chaining' pochodzi jednak ze znanej z roznych jezykow 
> koncepcji cascade expression.

Ktora szczegolnie uwuielbiaj aparsery synktatyki
Lepije im to zostawic niz "upubliczniac"

W/w to jednak "pryszcz".
Zycze powodzenia w debuggowaniu Twojej wersji.

AK

Seweryn Habdank-Wojewódzki wrote:
> Witam
> 
> a1 wrote:
> 
> 
>>Order o1 = new Order();
>>        customer.addOrder(o1);
>>         OrderLine line1 = new OrderLine(6, Product.find("TAL"));
>>         o1.addLine(line1);
>>         OrderLine line2 = new OrderLine(5, Product.find("HPK"));
>>         o1.addLine(line2);
>>         OrderLine line3 = new OrderLine(3, Product.find("LGV"));
>>         o1.addLine(line3);
>>         line2.setSkippable(true);
>>         o1.setRush(true);
>>
>>vs.
>>
>>         customer.newOrder()
>>                 .with(6, "TAL")
>>                 .with(5, "HPK").skippable()
>>                 .with(3, "LGV")
>>                 .priorityRush();
> 
> 
> To jest tendencyjna konstrukcja. 
Troche tak, wykozystalem przyklad bezposrednio ze strony Flower'a, ktory 
mial pokazac ze metod chaining moze byc calkiem przyjemny w odbiorze.
Ja nie twierdze ze to lek na cale zlo, ale moze byc uzyteczny (i 
cztelny) podczas gdy wiekszosc moich przedpiscow odrzuca ten pomysl, 
mimo ze nigdy nie uzywali w praktyce tego typu interfejsow. Z mojej 
strony to tyle bo nawracac nikogo nie mam  zamiaru.

-- 
a1 (Bartek Janusz) arcone1 gmail com

>> To jest tendencyjna konstrukcja. 
>Troche tak, wykozystalem przyklad bezposrednio ze strony Flower'a, ktory 
>mial pokazac ze metod chaining moze byc calkiem przyjemny w odbiorze.
>Ja nie twierdze ze to lek na cale zlo, ale moze byc uzyteczny (i 
>cztelny) podczas gdy wiekszosc moich przedpiscow odrzuca ten pomysl, 
>mimo ze nigdy nie uzywali w praktyce tego typu interfejsow. Z mojej 
>strony to tyle bo nawracac nikogo nie mam  zamiaru.

Ja tylko dodam, ze Fowler nalezy do tej rasy konsultantow, ktorzy wyciagna byle
trywialna pierdole na swiatlo dzienne, napisza na ten temat tuzin madrze
brzmiacych artykulow - w jednym i tylko jednym celu - zdobyc rozglos i
publicity.  Od tego bowiem zalezy przetrwanie jego konsultingowego biznesu.


A.
-- 
============= P o l N E W S ==============
     archiwum i przeszukiwanie newsów
        http://www.polnews.pl

Dnia Wed, 7 Jun 2006 15:19:12 +0200, Adam Karpierz skrobie:
> "a1" <a1@no.spam> wrote in message news:e66dmr$q62$1@inews.gazeta.pl...

> > Tragedia bo...? osobiscie nie widze zadnych przeciwskazan,

> 1. Wieksza bledogennosc - i to bledogennosc trudna niekiedy
>      do wykrycia.

E tam.

> 2. Nie widac "na rzecz czego"...
>      W celu upewniania koneiczne siegniecie do definicji klasy

To jest akurat norma ;)

> 3. Mozliwe ukryte neichciane tworzenie (i usuwanie) obiektow
>     tymczasowych (np w przypadku C++).

W C++ jest to optymalizowane (-fno-elide-constructor w gcc). Ja bym się tam
tym szczegółem nie przejmował.

>     Moze to powodowac paskudne efekty uboczne

I o to właśnie chodzi. Te efekty uboczne są całkowicie celowe.

> > a dobrze skonstruowany fluent interface moze byc bardzo wygodny w uzyciu.

> Nie widze wiekszej wygody od kasycznego zapisu.

> o.setX(x);
> o.setY(y);
> o.setZ(z);

Ciekawe, że w C++ powszechnie stosuje się:

cout << a1 << hex << a2 << a3;

i nikt nie widzi w tym niczego niezwykłego, ani tym bardziej błędogennego.



-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Dnia Wed, 07 Jun 2006 11:36:13 +0200, Piotr Kobzda skrobie:
> Przemek Pokrywka wrote:

> > Co Państwo myślą o praktyce zwracania przez takie metody obiektu 
> > deklarującej je klasy? Tzn.

> Jeśli praktyka owa ma na celu 'method chaining', czyli zbudowanie 
> 'fluent interfaces', to ma sens. W przeciwny przypadku jest IMHO tylko 
> zaciemniaczem kodu.

> Ciekawy jest natomiast ten RFE:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6373386

> Mnie, z przedstawionych tam, najbardziej przekonuje pomysł z 
> traktowaniem wszystkich metod obiektu zwracających 'void', jak 
> zwracających 'this'. Propozycja z jawnym 'this' w deklaracji mniej mi 
> już odpowiada, sens jednak ma, jeśli istnieją jakieś przeciwwskazania 
> dla propozycji wcześniejszej (których akurat, być może chwilowo, nie 
> dostrzegam...).

Przypomnę jeszcze tak na marginesie, że Smalltalk posiada konstrukcję, która
ułatwia korzystanie z "method chaining".

object setX:1 ; setY:2 ; setZ:3 .

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:

> Ciekawe, że w C++ powszechnie stosuje się:
>
> cout << a1 << hex << a2 << a3;
>
> i nikt nie widzi w tym niczego niezwykłego, ani tym bardziej błędogennego.

Ja widzę. Nie mogę zapamiętać, które ustawienia dotyczą tylko
następnej danej, a które pozostają na stałe. Poza tym ta konstrukcja
jest niemodularna: wszystkie możliwe parametry formatowania różnych
typów muszą być uwzględniane przez sam strumień.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Dnia Thu, 08 Jun 2006 20:35:31 +0200, Marcin 'Qrczak' Kowalczyk skrobie:
> Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:

> > Ciekawe, że w C++ powszechnie stosuje się:
> >
> > cout << a1 << hex << a2 << a3;
> >
> > i nikt nie widzi w tym niczego niezwykłego, ani tym bardziej błędogennego.

> Ja widzę. Nie mogę zapamiętać, które ustawienia dotyczą tylko
> następnej danej, a które pozostają na stałe. Poza tym ta konstrukcja
> jest niemodularna: wszystkie możliwe parametry formatowania różnych
> typów muszą być uwzględniane przez sam strumień.

Z tego co ja gdzieś czytałem (ale, nie ukrywam, nie jestem tego pewny, a nawet
mam wrażenie, że implementacje potrafiły się tu zachowywać różnie, często
nawet błędnie), to podobno manipulator ma ustawić flagę wyłącznie na następną
daną. Po jej wysłaniu powinien przywrócić flagi tak jak były. Te same flagi
można ustawiać metodami zamiast manipulatorami i wtedy ustawiają się na
trwale.

Moim zdaniem to zresztą bez sensu. Znacznie fajniej by wyglądało tak:

cout << a1 -hex << a2 << a3;

czy nawet:

cout << a1 << hex( a2 ) << a3;

Ale to dotyczy samego formatowania, a nie kwestii wywołania łańcuchowego.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

"Sektor van Skijlen" <ethouris@guess.if.gmail.com.is.valid.or.invalid> 
wrote:

> E tam.

Zwsze bylem pod wrazeniem glebi Twoich uzasadnien.

> To jest akurat norma ;)

>> 3. Mozliwe ukryte neichciane tworzenie (i usuwanie) obiektow
>>     tymczasowych (np w przypadku C++).
>
> W C++ jest to optymalizowane (-fno-elide-constructor w gcc).
> Ja bym się tam tym szczegółem nie przejmował.

Wykazujesz brak wyobrazni.
Krzyzyki ++ przeslaniaja ?.
Nie chodzi o optymalizacje.

> I o to właśnie chodzi. Te efekty uboczne są całkowicie celowe.

Ktore niekiedy bywaja niecelowe.

>> o.setX(x);
>> o.setY(y);
>> o.setZ(z);
>
> Ciekawe, że w C++ powszechnie stosuje się:
>
> cout << a1 << hex << a2 << a3;
>
> i nikt nie widzi w tym niczego niezwykłego

Niezwyklego nie.
C++sowe strumienie to najwiekszy idiotyzm i syf
jaki udalo mi sie spotkac w j.programowania.
Recz godna tepienia juz u najmlodszych adeptow C++.
Rzecz tak paskudna w pozniejszym maintenance ze godna zakazania.
Unikanie natomiast tej "paskudnosci" strumieni prowadzi prosto do
pojedynczych uzyc:

cout << a;

zamiast lancuchowych.

Nic niezwyklego bo idiotyzmy nie sa czyms niezwyklym.
To prawda.

AK

Dnia Thu, 8 Jun 2006 21:30:34 +0200, Adam Karpierz skrobie:
> "Sektor van Skijlen" <ethouris@guess.if.gmail.com.is.valid.or.invalid> 
> wrote:

> > E tam.

> Zwsze bylem pod wrazeniem glebi Twoich uzasadnien.

Cóż, to była wypowiedź mająca symbolizować powątpiewanie. To ty miałeś
uzasadnić. Ja nie przedstawiałem żadnej tezy, którą miałbym uzasadniać.

> > To jest akurat norma ;)

> >> 3. Mozliwe ukryte neichciane tworzenie (i usuwanie) obiektow
> >>     tymczasowych (np w przypadku C++).
> >
> > W C++ jest to optymalizowane (-fno-elide-constructor w gcc).
> > Ja bym się tam tym szczegółem nie przejmował.

> Wykazujesz brak wyobrazni.

No cóż, ciężko dyskutuje się z kimś, kto zamiast wiedzy woli wyobraźnię.

> Krzyzyki ++ przeslaniaja ?.
> Nie chodzi o optymalizacje.

O co? Słucham. Gdzie masz w C++ problem z ukrytym niechcianym tworzeniem i
usuwaniem obiektów tymczasowych.

> > I o to wła?nie chodzi. Te efekty uboczne s? całkowicie celowe.

> Ktore niekiedy bywaja niecelowe.

To wtedy ich nie programujemy.

> >> o.setX(x);
> >> o.setY(y);
> >> o.setZ(z);
> >
> > Ciekawe, że w C++ powszechnie stosuje się:
> >
> > cout << a1 << hex << a2 << a3;
> >
> > i nikt nie widzi w tym niczego niezwykłego

> Niezwyklego nie.
> C++sowe strumienie to najwiekszy idiotyzm i syf
> jaki udalo mi sie spotkac w j.programowania.
> Recz godna tepienia juz u najmlodszych adeptow C++.

Jakie znasz lepsze - pomijając formatujące - metody wysyłania danych do
strumienia, które można zastosować w językach o statycznej typizacji.

Tak, wiem. Też wolę puts "$a1 [format %x $a2] $a3".

> Rzecz tak paskudna w pozniejszym maintenance ze godna zakazania.
> Unikanie natomiast tej "paskudnosci" strumieni prowadzi prosto do
> pojedynczych uzyc:

> cout << a;

> zamiast lancuchowych.

Nie rozumiem. Co to ma do rzeczy? Dlaczego niby ta łańcuchowość ma być
problemem?

Taa, już widzę, jak piszesz:

cout << a1;
cout << hex << a2;
cout << a3;


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

On Thu, 08 Jun 2006 09:53:53 +0200, "Aleksander Galicki" <no@no.com>
wrote:

>>> To jest tendencyjna konstrukcja. 
>>Troche tak, wykozystalem przyklad bezposrednio ze strony Flower'a, ktory 
>>mial pokazac ze metod chaining moze byc calkiem przyjemny w odbiorze.
>>Ja nie twierdze ze to lek na cale zlo, ale moze byc uzyteczny (i 
>>cztelny) podczas gdy wiekszosc moich przedpiscow odrzuca ten pomysl, 
>>mimo ze nigdy nie uzywali w praktyce tego typu interfejsow. Z mojej 
>>strony to tyle bo nawracac nikogo nie mam  zamiaru.
>
>Ja tylko dodam, ze Fowler nalezy do tej rasy konsultantow, ktorzy wyciagna byle
>trywialna pierdole na swiatlo dzienne, napisza na ten temat tuzin madrze
>brzmiacych artykulow - w jednym i tylko jednym celu - zdobyc rozglos i
>publicity.  Od tego bowiem zalezy przetrwanie jego konsultingowego biznesu.

Rozglos i publicity to tylko srodki. Celem jest szmal.

A.L.

On Thu, 8 Jun 2006 21:39:48 +0000 (UTC), Sektor van Skijlen
<ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:

>D
>
>Nie rozumiem. Co to ma do rzeczy? Dlaczego niby ta łańcuchowość ma być
>problemem?
>
>Taa, już widzę, jak piszesz:
>
>cout << a1;
>cout << hex << a2;
>cout << a3;


No i jak tam, Panie Sektor? O garbage collection i memory management
juz sie Pan poduczyl?...

A.L.

Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:

> Z tego co ja gdzieś czytałem (ale, nie ukrywam, nie jestem tego
> pewny, a nawet mam wrażenie, że implementacje potrafiły się tu
> zachowywać różnie, często nawet błędnie), to podobno manipulator ma
> ustawić flagę wyłącznie na następną daną. Po jej wysłaniu powinien
> przywrócić flagi tak jak były. Te same flagi można ustawiać metodami
> zamiast manipulatorami i wtedy ustawiają się na trwale.

GCC-4.1.0:

#include <iostream>
#include <iomanip>
using namespace std;
int main() {
   cout << 1.2345 << endl;
   cout << setw(10) << setprecision(2) << 1.2345 << endl;
   cout << 1.2345 << endl;
}

1.2345
       1.2
1.2

Czyli wygląda jakby setw odnosiło się tylko do następnej danej,
a setprecision było trwałe. Nie chce mi się szukać, jak być
powinno.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Dnia Thu, 08 Jun 2006 21:24:56 -0500, A.L. skrobie:
> On Thu, 8 Jun 2006 21:39:48 +0000 (UTC), Sektor van Skijlen
> <ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:

> >D
> >
> >Nie rozumiem. Co to ma do rzeczy? Dlaczego niby ta łańcuchowość ma być
> >problemem?
> >
> >Taa, już widzę, jak piszesz:
> >
> >cout << a1;
> >cout << hex << a2;
> >cout << a3;


> No i jak tam, Panie Sektor? O garbage collection i memory management
> juz sie Pan poduczyl?...

Jestem jeszcze w trakcie. Cierpliwości :P

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"