🚀 go-pugleaf

Michal Przybylek <mrp@neostrada.pl> napisał(a): 

> Zaprzeczyl z cala stanowczoscia i odparl, ze co prawda syntaktyka byla
> inspirowana przez C++, ale semantycznie bazowali na ML'u (polimorfizm
> parametryczny Minlera) i Haskellu (type classes Wadlera i Bletta).

istotnie

Wielka różnica (choć nie jedyna) pomiędzy template'ami C++ a resztą jest taka,
że w C++ jak się aplikuje templat'e A<class T> do klasy B, to nie musi klasa B
posiadać wszystkich metod używanych przez template A, a jedynie te które są
używane przez metody A<B> faktycznie używane przez resztę kodu. Tak w duchu
latent-typing.

Natomiast w reszcie (Java, ML, Haskell), żeby zrobić A<B>, B musi mieć
wszystkie metody które są używane przez szablon A.

Tak mi się w każdym razie wydaje.

Jest nawet na to rozróżnienie jakaś ładna nazwa, ale nie pamiętam, możecie
zapytać na LTU.

dlaczego dla ludzi o mocnych nerwach? :-)

MS

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

On Sat, 2 Sep 2006 19:36:58 +0000 (UTC), "Marcin Stefaniak"
<matmis@gazeta.SKASUJ-TO.pl> wrote:

>Michal Przybylek <mrp@neostrada.pl> napisał(a): 
>
>> Zaprzeczyl z cala stanowczoscia i odparl, ze co prawda syntaktyka byla
>> inspirowana przez C++, ale semantycznie bazowali na ML'u (polimorfizm
>> parametryczny Minlera) i Haskellu (type classes Wadlera i Bletta).
>
>istotnie
>
>Wielka różnica (choć nie jedyna) pomiędzy template'ami C++ a resztą jest taka,
>że w C++ jak się aplikuje templat'e A<class T> do klasy B, to nie musi klasa B
>posiadać wszystkich metod używanych przez template A, a jedynie te które są
>używane przez metody A<B> faktycznie używane przez resztę kodu. Tak w duchu
>latent-typing.
>
>Natomiast w reszcie (Java, ML, Haskell), żeby zrobić A<B>, B musi mieć
>wszystkie metody które są używane przez szablon A.
>
>Tak mi się w każdym razie wydaje.

Zle ci sie wydaje. W javie mozna napisac LinkedList<String> i jako
zywo String nie ma nic wspolnego z LinkedList

Poza tym, Java nei ma "szablonow".

A.L.

On Sat, 2 Sep 2006 22:56:02 +0200, "Michal Przybylek"
<mrp@neostrada.pl> wrote:

>"Marcin Stefaniak" <matmis@gazeta.SKASUJ-TO.pl> wrote:
>
>> Tak mi się w każdym razie wydaje.
>
>Nie tu chodzi o cos innego. Duzo bardziej fundamentalnego.
>
>Roznica jest duzo bardziej fundamentalna. C++ nie ma parametrycznego
>polimorfizmu tylko makrogenerator, ktory niejako przypadkowo okazal sie miec
>funkcjonalnosc rownowazna parametrycznemu polimorfizmowi.

No, no... Panie Przybylek, niech Pan uwaza... Jak zauwazyl Pan
Sektor, niejaki Pan Wojtek Surowka juz 8 lat temu udowodnil ze
"templates" w C++ to jednak nie makrogenerator. Cytuje Pana Sektora:
"Żeby dodać sprawie smaczku, przypomnę, że właśnie te 8 lat temu
Wojtek Surówka podał przykład wzorca i jego instancji, która
pokazała, że wzorce jednak NIE zachowują się jak makrogenerator..."

Narazi sie Pan nie tylko panu Sektorow, ale i jego Miszczowi i Guru,
Panu Surowce. No i wyjdzie Pan na nieuka. I nawet znajomosc teorii
kategorii Panu nei pomoze. Zwlaszcza ze owa teoria okazala sie
zupelnie nieprzydatna w C++, co dowodzi jej bezwartosciowosci, zeby
nie powiedziec - nieslusznosci.

A.L.

"Marcin Stefaniak" <matmis@gazeta.SKASUJ-TO.pl> wrote:

> Tak mi się w każdym razie wydaje.

Nie tu chodzi o cos innego. Duzo bardziej fundamentalnego.

Roznica jest duzo bardziej fundamentalna. C++ nie ma parametrycznego
polimorfizmu tylko makrogenerator, ktory niejako przypadkowo okazal sie miec
funkcjonalnosc rownowazna parametrycznemu polimorfizmowi.

W paramatrycznym polimorfizmie istotne jest to, ze mamy _jedna_ dostatecznie
bogata funkcje o porzadnych wlasnosciach.

W C++ dostajemy "szablon funkcji", z ktorego kompilator moze nam usluznie
wygenerowac konkretna funkcje (ale nie wygeneruje, np. kiedy napisalismy
specjalna wersje z reki).

Standardowy parametryczny polimorfizm ma ladna interpretacje kategoryjna
(np. w modelach PER) - jest to faibracja, w ktorej morfizmy sa _pojedynczym_
zyjatkiem (np. w PER _jedna_ klasa rownowaznosci), nie zas kolekcja zyjatek,
z ktorej wyciagamy to co nam jest potrzebebne po typie.

> dlaczego dla ludzi o mocnych nerwach? :-)

Nie chce isc do pierdla, kiedy Sektor popelni samobojstwo dowiedziawszy sie
kolejnej straszliwej prawdy...


mp

On Sat, 02 Sep 2006 15:08:55 -0500, A.L. <alewando@fala2005.com>
wrote:

>On Sat, 2 Sep 2006 19:36:58 +0000 (UTC), "Marcin Stefaniak"
><matmis@gazeta.SKASUJ-TO.pl> wrote:
>
>>Michal Przybylek <mrp@neostrada.pl> napisał(a): 
>>
>>> Zaprzeczyl z cala stanowczoscia i odparl, ze co prawda syntaktyka byla
>>> inspirowana przez C++, ale semantycznie bazowali na ML'u (polimorfizm
>>> parametryczny Minlera) i Haskellu (type classes Wadlera i Bletta).
>>
>>istotnie
>>
>>Wielka różnica (choć nie jedyna) pomiędzy template'ami C++ a resztą jest taka,
>>że w C++ jak się aplikuje templat'e A<class T> do klasy B, to nie musi klasa B
>>posiadać wszystkich metod używanych przez template A, a jedynie te które są
>>używane przez metody A<B> faktycznie używane przez resztę kodu. Tak w duchu
>>latent-typing.
>>
>>Natomiast w reszcie (Java, ML, Haskell), żeby zrobić A<B>, B musi mieć
>>wszystkie metody które są używane przez szablon A.
>>
>>Tak mi się w każdym razie wydaje.
>
>Zle ci sie wydaje. W javie mozna napisac LinkedList<String> i jako
>zywo String nie ma nic wspolnego z LinkedList

Sorry, zle zrozumialem pytanie. Odpowiedz jest "tak".

A.L.

A.L. <alewando@fala2005.com> writes:

[...]

> I nawet znajomosc teorii kategorii Panu nei pomoze.

A'propos teorii kategorii -- czy może ktoś wie, jak się mają kategorie
smalltalkowe do kategorii matematycznych?

"Piotr Dembiński" <pdemb@gazeta.pl> wrote:

> A'propos teorii kategorii -- czy może ktoś wie, jak się mają
> kategorie smalltalkowe do kategorii matematycznych?

Mniej wiecej tak jak domknietosc drzwi, do domknietosci w matematyce. Tzn.:

- nie ma czegos takiego jak "domknietosc w matematyce" - termin jest
niejasny, co nie oznacza, ze bzdurny,

- nawet po doprecyzowaniu, falszywe byloby stwierdzenie, ze zwiazku pomiedzy
tymi pojeciami nie ma - zwiazkow jest cale mnowstwo, przy czym nie jestem
przekonany, czy z sensem da sie o tych zwiazkach mowic.


mp

Michal Przybylek <mrp@neostrada.pl> napisał(a): 

> "Marcin Stefaniak" <matmis@gazeta.SKASUJ-TO.pl> wrote:
> 
> > Tak mi się w każdym razie wydaje.
> 
> Nie tu chodzi o cos innego. Duzo bardziej fundamentalnego.

Pomijając te kategoryjne wtręty, których sorry, ale nie rozumiem (czas się
zapisać w końcu na wykład z teorii kategorii), chodzi o to że w C++ można
bardziej specyficzne konkretyzacje szablonu nad-definiować. I że można robić
templaty od wartości inta. I że w ogóle można robić fajowe meta-programowanie. 

Faktycznie, to też jest duża różnica w porównaniu do Javo'wego podejścia.

-MS

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

"Michal Przybylek" <mrp@neostrada.pl> writes:

> "Piotr Dembiński" <pdemb@gazeta.pl> wrote:
>
>> A'propos teorii kategorii -- czy może ktoś wie, jak się mają
>> kategorie smalltalkowe do kategorii matematycznych?
>
> Mniej wiecej tak jak domknietosc drzwi, do domknietosci 
> w matematyce. Tzn.:
>
> - nie ma czegos takiego jak "domknietosc w matematyce" - termin jest
> niejasny, co nie oznacza, ze bzdurny,
>
> - nawet po doprecyzowaniu, falszywe byloby stwierdzenie, ze zwiazku
> pomiedzy tymi pojeciami nie ma - zwiazkow jest cale mnowstwo, przy
> czym nie jestem przekonany, czy z sensem da sie o tych zwiazkach
> mowic.

Spojrzałem sobie na stronę teorii kategorii w angielskiej Wikipedii 
i wygląda na to, że gdyby przyłożyć teorię kategorii do programów
komputerowych, to jest to dopełnienie refaktoryzacji 
i restrukturyzacji: teoria kategorii bada przekształcenia zachowujące
strukturę, a sensem większości przekształceń refaktoryzacyjnych jest
zmiana struktury przy jednoczesnym zachowaniu innych własności 
(równoznaczność odniesień i działań).

-- 
http://www.piotr.dembiński.prv.pl

'Giving people a dynamically-typed language does not mean that they write
dynamically-typed programs.'  John Aycock, 'Aggressive Type Inference'

"Piotr Dembiński" <pdemb@gazeta.pl> wrote:

> Spojrzałem sobie na stronę teorii kategorii w angielskiej Wikipedii
> i wygląda na to, że gdyby przyłożyć teorię kategorii do programów
> komputerowych, to jest to dopełnienie refaktoryzacji

Przylozyc mozna Ci paskiem na tylek za testowanie na pl.comp.objects
programow do generowania belkotu (wierze, ze nie testowales programu, ktory
dostales od Matki Natury).

Zreszta, to co pisza na wikipedii nie jest dokladnie tym, co powinni czytac
ludzie chcacy sobie wyrobic wyobrazenie o tym czym jest CT.

Teoria kategorii nie jest o abstrakcji. Teoria kategorii jest o
bezelementowym podejsciu do uprawiania matematyki. To, ze mozemy w CT
pracowac na wysokim poziomie abstrakcji, jest raczej konsekwencja wlasciwego
podejscia do opisu pojec.

Wyobrazenie, ze teoria kategorii jest o abstrakcji to efekt wieloletnich
dzialan destrukcyjnych systemu nauczania na mlode mozgi przyszlych
scjentystow i wpajania im od najmlodszych lat elementocentrycznego podejscia
do matematyki. Sila destrukcji jest tak silna, ze niektorzy nie sa juz w
stanie kiedykolwiek pozniej oderwac sie od tego podejscia...


p.s. Nie bede dostepny przez kilka dni, wiec jezeli chesz zadac jakies
pytanie, masz czas aby dobrze i dlugo sie nad tym pytaniem zastanowic.


mp

Dnia Sat, 2 Sep 2006 22:56:02 +0200, Michal Przybylek skrobie:
> "Marcin Stefaniak" <matmis@gazeta.SKASUJ-TO.pl> wrote:

> > Tak mi się w każdym razie wydaje.

> Nie tu chodzi o cos innego. Duzo bardziej fundamentalnego.

> Roznica jest duzo bardziej fundamentalna. C++ nie ma parametrycznego
> polimorfizmu tylko makrogenerator, ktory niejako przypadkowo okazal sie miec
> funkcjonalnosc rownowazna parametrycznemu polimorfizmowi.

lol ;) merytoryczne aż do bólu.

> W paramatrycznym polimorfizmie istotne jest to, ze mamy _jedna_ dostatecznie
> bogata funkcje o porzadnych wlasnosciach.

Na tej samej zasadzie można udowadniać, że polimorfizm w programowaniu
obiektowym polega na tym, że mamy _jedną_ dostatecznie bogatą klasę o
porządnych właściwościach.

> W C++ dostajemy "szablon funkcji", z ktorego kompilator moze nam usluznie
> wygenerowac konkretna funkcje (ale nie wygeneruje, np. kiedy napisalismy
> specjalna wersje z reki).

Zawsze mnie bawiło, jak ktoś mówił o "generowaniu funkcji" przez kompilator.

> Standardowy parametryczny polimorfizm ma ladna interpretacje kategoryjna
> (np. w modelach PER) - jest to faibracja, w ktorej morfizmy sa _pojedynczym_
> zyjatkiem (np. w PER _jedna_ klasa rownowaznosci), nie zas kolekcja zyjatek,
> z ktorej wyciagamy to co nam jest potrzebebne po typie.

Tłumacząc ten śmieszny bełkot na normalny język: w Javie aby można było
zastosować dany typ jako parametr wzorca, to musi mieć on na starcie
odpowiednie właściwości gwarantowane (jeśli są wykorzystywane; przykład z
List<String> jest przykładem, gdzie akurat nie są wykorzystywane, poza
samym faktem, że String musi być typem klasowym). Nawiasem mówiąc, w C++
kiedyś też tak było (z tą tylko różnicą, że nie można nadawać tych gwarancji
przez deklarację koncepcji).

Ja tam na upartego dopatrywałbym się wspólnego źródła generyków Javy i wzorców
w C++, ale dalej te języki wybrały inne drogi. Można dyskutować o tym, jakie
są odpowiednie wady i zalety obu rozwiązań. Różnica jest mniej więcej taka,
jakby mieć programowanie obiektowe oparte na klasach oraz programowanie
obiektowe nie oparte na klasach, tylko każdy obiekt dostaje arbitralnie
określony komunikat i ma na niego odpowiedzieć (albo zgłosić błąd). Drugie
rozwiązanie jest bardziej generyczne, bo nie wprowadza zależności od definicji
klasy. Ale rozwiązanie z klasami jest lepsze pod tym względem, że lepiej
porządkuje kod. Oczywiście w implementacji statycznej ten fakt ma znacznie
mniejsze znaczenie.

Ale z wami przecież nie da się dyskutować inaczej, niż plując na wszystko, co
reprezentuje sobą C++, wzbogacając wszechogarniającą - jak to się p. Andrzej
Lewandowski raczył wyrazić - amatorszyznę.

> > dlaczego dla ludzi o mocnych nerwach? :-)

> Nie chce isc do pierdla, kiedy Sektor popelni samobojstwo dowiedziawszy sie
> kolejnej straszliwej prawdy...

Jasne - gdybym się przejmował takim bełkotem, jak tu powyżej to
zaprezentowałeś, to prawdopodobnie nigdy byś nie widział mnie na tej grupie.

-- 
//  _    ___         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 Sun, 3 Sep 2006 17:49:15 +0000 (UTC), Marcin Stefaniak skrobie:
> Michal Przybylek <mrp@neostrada.pl> napisał(a): 

> > "Marcin Stefaniak" <matmis@gazeta.SKASUJ-TO.pl> wrote:
> > 
> > > Tak mi się w każdym razie wydaje.
> > 
> > Nie tu chodzi o cos innego. Duzo bardziej fundamentalnego.

> Pomijając te kategoryjne wtręty, których sorry, ale nie rozumiem (czas się
> zapisać w końcu na wykład z teorii kategorii), chodzi o to że w C++ można
> bardziej specyficzne konkretyzacje szablonu nad-definiować. I że można robić
> templaty od wartości inta.

To ostatnie da się również w C#. I, w odróżnieniu od Javy, nie jest to tam int
opakowany w obiekt.

> I że w ogóle można robić fajowe meta-programowanie.

Tak, chociaż przyznam szczerze, że nie widzę jakiegoś dużego zastosowania do
tego, co jest choćby w boost::mpl. Metaprogramowanie we wzorcach w C++ wyszło
zupełnym przypadkiem; gdyby to wyszło wcześniej, być może pomyśliliby o
jakiejś wygodniejszej składni.

Tyle że wtedy - dokładnie tak samo jak w przypadku Javy - gdyby to był język
projektowany od początku, to miałby wtedy pewnie tyle użytkowników, co i inne
języki projektowane od początku.



-- 
//  _    ___         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"

Witam

Sektor van Skijlen wrote:

> Tak, chociaż przyznam szczerze, że nie widzę jakiegoś dużego zastosowania
> do tego, co jest choćby w boost::mpl.

Z przykrością stwierdzam, że się mylisz. Proponuję głęboką lekturę oraz case
study czegoś co się nazywa concept traits. Szczególnie ważne pytania
zadawane kompilatorowi moga być z serii has_something<T> w połączeniu z
IF_<S,T,U>. To jest naprawdę cenne w przypadku bardzo restrykcyjnych
kontraktów na klasy parametryzujące szablony.

Pozdrawiam.

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

Parę linków o generykach w Javie i o kompatybilności:

http://lambda-the-ultimate.org/node/1684#comment-20955

Wybrane cytaty:

"Sun even went so far as to censor any discussion of these issues from
their forums! They performed a huge selective deletion of almost every
thread that mentioned these changes. (I do have copies of some of the
threads from Google's cache if anyone's interested.) They refused to
discuss the technical reasons, either, except for some thin reasons
that were easily dismissed (e.g. "we had to add some new exceptions to
support this.")"

"This non-migration compatibility was compromised even though changes
to the language and underlying VM were not needed for the upgrade -
(owing mostly to the original collection classes being badly designed
such that a clean set of API's were in order)."

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

Marcin 'Qrczak' Kowalczyk <qrczak@knm.org.pl> napisał(a): 

> Parę linków o generykach w Javie i o kompatybilności:
> 
> http://lambda-the-ultimate.org/node/1684#comment-20955

Tam tlumaczy sie Neal G. od Sun i w jednej z wypowiedzi wymienia ciurkiem N
rzeczy ktore sa w 1.5 i dla ktorych nie ma szans by ruszyly na 1.4. Z tego
wynika, ze Sun dal d.. z wymuszaniem type erasure. 

> "This non-migration compatibility was compromised even though changes
> to the language and underlying VM were not needed for the upgrade -
> (owing mostly to the original collection classes being badly designed
> such that a clean set of API's were in order)."

Ale przeczytales uwaznie to co sam cytujesz? (to bylo o zmianie z 1.1 to 1.2)


A.


-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

"Aleksander Galicki" <tretete@gazeta.SKASUJ-TO.pl> writes:

>> "This non-migration compatibility was compromised even though changes
>> to the language and underlying VM were not needed for the upgrade -
>> (owing mostly to the original collection classes being badly designed
>> such that a clean set of API's were in order)."
>
> Ale przeczytales uwaznie to co sam cytujesz? (to bylo o zmianie z 1.1 to 1.2)

Wiem. To raczej dla tych, którzy zachowują się, jakby Java była tworem
doskonałym.

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

Marcin 'Qrczak' Kowalczyk <qrczak@knm.org.pl> napisał(a): 

> > Ale przeczytales uwaznie to co sam cytujesz? (to bylo o zmianie z 1.1 to 1.2)
> 
> Wiem. To raczej dla tych, którzy zachowują się, jakby Java była tworem
> doskonałym.

Heh. Bardziej zywiolowej reakcji spodziewaj sie na anglojezycznych forach
poswieconych Lisp. 
BTW w Javie stare niekonsekwencje (dolaczenie paskudnych typow prymitywnych) w
polaczeniu z nowymi ficzerami daje nowe kwiatki (choc niegrozne): co zwroci
Arrays.asList(new Integer[]{1,2}) a co Arrays.asList(new int[]{1,2})?


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Aleksander Galicki wrote:

> Marcin 'Qrczak' Kowalczyk <qrczak@knm.org.pl> napisał(a): 
> 
>> Parę linków o generykach w Javie i o kompatybilności:
>>
>> http://lambda-the-ultimate.org/node/1684#comment-20955
> 
> Tam tlumaczy sie Neal G. od Sun i w jednej z wypowiedzi wymienia ciurkiem N
> rzeczy ktore sa w 1.5 i dla ktorych nie ma szans by ruszyly na 1.4. Z tego
> wynika, ze Sun dal d.. z wymuszaniem type erasure. 

Szanse by ruszyły są, czego namacalnym dowodem Retroweaver czy 
Retrotranslator, /forward compatibility/ jest jednak generalnie rzecz 
biorąc mało istotna.

I nie do końca też takie pewne jest dla mnie, że Sun dał d..
W innym miejscu Gafter tłumaczy, że nie znaleźli po prostu lepszego 
rozwiązania.

Fakty są takie, że Java 5 (a w szczególności jej Generics) jest 
kompatybilna wstecz na poziomie binarniów w 100%. Drobne problemy mogą 
być jedynie z kompatybilnością wsteczną na poziomie źródeł -- 
spowodowane np. autoboxingiem, czy zmianą jakiegoś API.

I zawdzięcza tę kompatybilność Java m.in. właśnie wymazywaniu.

Często podawanym kontrargumentem jest, że niby w C# udało się to samo 
uzyskać bez wymazywania. Co jest oczywiście mydleniem oczu, gdyż jak 
wiadomo rozwiązanie polega na dodaniu zupełnie nowych, generycznych 
wersji starych klas, co z kompatybilnością wsteczną uzyskaną w Javie ma 
niewiele wspólnego, żeby nie powiedzieć, że nic.


Jak już, więc wcześniej pisałem, jestem za rezygnacją z wymazywania, 
czyli chętnie zobaczyłbym "reifable" typy generyczne w Javie, jednak 
tylko pod warunkiem, że poza korzyściami, które z tego płyną, nie narobi 
się w Javie jeszcze większa kaszana...


piotr

Aleksander Galicki wrote:

> Marcin 'Qrczak' Kowalczyk <qrczak@knm.org.pl> napisał(a): 
> 
>>> Ale przeczytales uwaznie to co sam cytujesz? (to bylo o zmianie z 1.1 to 1.2)
>> Wiem. To raczej dla tych, którzy zachowują się, jakby Java była tworem
>> doskonałym.
> 
> Heh. Bardziej zywiolowej reakcji spodziewaj sie na anglojezycznych forach
> poswieconych Lisp.

Być może. Tu zaś wcale bym się tego nie spodziewał. Nie sądzę, po 
prostu, by ktokolwiek kto zna i używa Javy uważał ją za "twór doskonały"...

> BTW w Javie stare niekonsekwencje (dolaczenie paskudnych typow prymitywnych) w
> polaczeniu z nowymi ficzerami daje nowe kwiatki (choc niegrozne): co zwroci
> Arrays.asList(new Integer[]{1,2}) a co Arrays.asList(new int[]{1,2})?

W tym ogródku jest też taki kwiatek:

     List<Integer> list = new ArrayList<Integer>();
     list.add(123);
     list.remove(123);

Ile elementów pozostanie na liście po wykonaniu?

Są to jednak wszytko drobiazgi, które gdy zna się język i biblioteki z 
których się korzysta nie stanowią problemu.


piotr

Piotr Kobzda <pikob@gazeta.pl> writes:

> Często podawanym kontrargumentem jest, że niby w C# udało się to samo
> uzyskać bez wymazywania.

Ano, takie generyki w języku w stylu Javy/C# mi się podobają.

> Co jest oczywiście mydleniem oczu, gdyż jak wiadomo rozwiązanie
> polega na dodaniu zupełnie nowych, generycznych wersji starych klas,
> co z kompatybilnością wsteczną uzyskaną w Javie ma niewiele
> wspólnego, żeby nie powiedzieć, że nic.

Jak to? Stare programy pozostają poprawne. W czym wsteczna
kompatybilność generycznych kolekcji w C# jest gorsza od wstecznej
kompatybilności nowego frameworku kolekcji w Javie 1.2?

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

Marcin 'Qrczak' Kowalczyk wrote:

>> Co jest oczywiście mydleniem oczu, gdyż jak wiadomo rozwiązanie
>> polega na dodaniu zupełnie nowych, generycznych wersji starych klas,
>> co z kompatybilnością wsteczną uzyskaną w Javie ma niewiele
>> wspólnego, żeby nie powiedzieć, że nic.
> 
> Jak to? Stare programy pozostają poprawne. W czym wsteczna
> kompatybilność generycznych kolekcji w C# jest gorsza od wstecznej
> kompatybilności nowego frameworku kolekcji w Javie 1.2?

Ze starym kodem bezpośrednich problemów nie ma.

Ale powiedzmy, że mam starą, niegeneryczną bibliotekę, którą chcę użyć w 
swoim nowym kodzie. W podejściu .NETa musisz korzystać ze starych klas, 
ewentualnie ich obiekty przekształcać z/do postaci generycznej. W Javie, 
dzięki /raw types/, mogę z taką biblioteką rozmawiać po staremu (czyli 
jak w .NEcie), lub też, mając świadomość wymazywania, zakryć kilka 
ostrzeżeń rzutowania (@SuppressWarnings) i z biblioteką współpracować po 
nowemu.

Inny przykład, chcę użyć zserializowanych kolekcji ze starego programu w 
nowym, w .Necie dostanę stare kolekcje, w Javie mam to co trzeba.
A może to być nie bez znaczenia w środowisku wielu współpracujących se 
sobą serwerów.

Oczywiście, nie są to jakieś potężne problemy, z punktu widzenia 
biznesowego bardziej jednak wydaje mi się istotne, niż to, że np. nie 
mogę zrobić nowej tablicy typu generycznego nie przekazując jawnie typu. 
Choć zdaję też sobie sprawę, że może mi się to tylko wydawać. :)


piotr

Piotr Kobzda <pikob@gazeta.pl> writes:

> Ale powiedzmy, że mam starą, niegeneryczną bibliotekę, którą chcę użyć
> w swoim nowym kodzie. W podejściu .NETa musisz korzystać ze starych
> klas, ewentualnie ich obiekty przekształcać z/do postaci generycznej.
> W Javie, dzięki /raw types/, mogę z taką biblioteką rozmawiać po
> staremu (czyli jak w .NEcie), lub też, mając świadomość wymazywania,
> zakryć kilka ostrzeżeń rzutowania (@SuppressWarnings) i z biblioteką
> współpracować po nowemu.

To rozumiem, ale w Javie była podobna sprawa przy migracji Vector
na ArrayList, Hashtable na HashMap, Enumeration na Iterator itd.
Skoro tamto było do zaakceptowania, to nie rozumiem, dlaczego
podejście do generycznych kolekcji w C# by nie było.

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

Marcin 'Qrczak' Kowalczyk wrote:

> To rozumiem, ale w Javie była podobna sprawa przy migracji Vector
> na ArrayList, Hashtable na HashMap, Enumeration na Iterator itd.

Tylko podobna. Przed Javą 2 Collections Frameworka po prostu w Javie nie 
było. Jak się pojawił trzeba było istniejące klasy wpakować w nowe, 
szersze i lepiej zaprojektowane API. Czyli był to naturalny ich rozwój.
W .NEcie mamy sytuację nieco inną, nowe API jest zgodne z poprzednim, 
żadnego specjalnego prograsu tam nie ma, jest tylko nowe pudełko.

> Skoro tamto było do zaakceptowania, to nie rozumiem, dlaczego
> podejście do generycznych kolekcji w C# by nie było.

Nie mówię, że nie jest do zaakceptowania. Ja np. zaakceptowałem. :)
Pytałeś co uważam za wadę .NETowego podejścia.


piotr

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

> > Roznica jest duzo bardziej fundamentalna. C++ nie ma parametrycznego
> > polimorfizmu tylko makrogenerator, ktory niejako przypadkowo okazal sie
miec
> > funkcjonalnosc rownowazna parametrycznemu polimorfizmowi.
>
> lol ;) merytoryczne aż do bólu.

Przeciez dalej to uzasadniam. To co jest w C++ to _nie_ jest polimorfizm
parametryczny (a przynajmniej ja nie potrafie tego interpretowac jak
polimorfizmu parametrycznego).

Tylko jeszcze raz uwazaj. Ja nie wartosciuje tutaj szablonow z C++. To Ty
jestes uprzejmy odbierac w bledny sposob to co pisze i zwiazywac podawane
fakty z krytyka C++ (choc moim zdaniem sluszna, ale ten aspekt mnie
kompletnie tutaj nie interesuje).

> > W paramatrycznym polimorfizmie istotne jest to, ze mamy
> > _jedna_ dostatecznie bogata funkcje o porzadnych wlasnosciach.
>
> Na tej samej zasadzie można udowadniać, że polimorfizm w programowaniu
> obiektowym polega na tym, że mamy _jedną_ dostatecznie bogatą klasę o
> porządnych właściwościach.

Przeciez dalej to uzasadnilem. To nie w ogole nie jest dowod czegokolwiek.

Ja uzywam potocznego jezyka, ale tylko jako plaszczyka dla pewnych
matematycznych pojec. W szczegolnosci, kiedy pisze to powyzsze mam w glowie
dobry model (a raczej klase modeli) pewnego rodzaju polimorficznego rachunku
lambda.

> > W C++ dostajemy "szablon funkcji", z ktorego kompilator moze nam
usluznie
> > wygenerowac konkretna funkcje (ale nie wygeneruje, np. kiedy napisalismy
> > specjalna wersje z reki).
>
> Zawsze mnie bawiło, jak ktoś mówił o "generowaniu funkcji" przez
kompilator.

Oczywiscie, ja sie nieslusznie odwoluje do implementacji jezyka. Ale tylko
dlatego, ze jest to w tym przypadku dobrym zrozumieniem semantyki (ktorej "z
reki" formalnie nie jestem w stanie podac ; sorry, semantyka szablonow z C++
jest mocno niestandardowa).

> > Standardowy parametryczny polimorfizm ma ladna interpretacje kategoryjna
> > (np. w modelach PER) - jest to faibracja, w ktorej morfizmy sa
_pojedynczym_
> > zyjatkiem (np. w PER _jedna_ klasa rownowaznosci), nie zas kolekcja
zyjatek,
> > z ktorej wyciagamy to co nam jest potrzebebne po typie.
>
> Tłumacząc ten śmieszny bełkot na normalny język:
> w Javie aby można było zastosować dany typ jako parametr wzorca, to musi
> mieć on na starcie odpowiednie właściwości gwarantowane

Przeciez gdybys zadal sobie choc odrobine trudu, szybko bys odgadl, ze na
pewno powyzszy fragment nie jest akurat o tym.

A odgadl bys z tad, ze problem o ktorym piszesz wczesniej podniosl Marcin
Stefaniak (to, ze w Javie mamy (F)bounded pp) i ja wlasnie na ten post
odpowiadalem, ze moim zdaniem problem lezy duzo nizej.


mp

"Michal Przybylek" <mrp@neostrada.pl> wrote:
> Nie tu chodzi o cos innego. Duzo bardziej fundamentalnego.
>
> Roznica jest duzo bardziej fundamentalna. C++ nie ma parametrycznego
> polimorfizmu tylko makrogenerator, ktory niejako przypadkowo okazal sie 
> miec
> funkcjonalnosc rownowazna parametrycznemu polimorfizmowi.
>
> W paramatrycznym polimorfizmie istotne jest to, ze mamy _jedna_ 
> dostatecznie
> bogata funkcje o porzadnych wlasnosciach.
>
> W C++ dostajemy "szablon funkcji", z ktorego kompilator moze nam usluznie
> wygenerowac konkretna funkcje (ale nie wygeneruje, np. kiedy napisalismy
> specjalna wersje z reki).

Dokladnie !.
Dlatego chocby nie wiem co sie dzialo to C++ templates w swej istocie
zawsze pozostana czyms w rodzaju makrogeneratora.
Cala ich istota (a nieszczegoly implementacyjne itp) jest tak blisko
makrogeneracji jak daleko od prawdziwego polimorfizmu parametrycznego
(czy jak to tam nazwac).

PS: Sektor sie chyba rozchoruje :)

AK

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

>> W paramatrycznym polimorfizmie istotne jest to, ze mamy _jedna_ 
>> dostatecznie
>> bogata funkcje o porzadnych wlasnosciach.
>
> Na tej samej zasadzie można udowadniać, że polimorfizm w programowaniu
> obiektowym polega na tym, że mamy _jedną_ dostatecznie bogatą klasę o
> porządnych właściwościach.

Nie zauwazyles literowki ?

AK 

"Seweryn Habdank-Wojewódzki" <habdank@gmail.com> wrote:

>> Tak, chociaz przyznam szczerze, ze nie widze jakiegos duzego zastosowania
>> do tego, co jest chocby w boost::mpl.
>
> Z przykroscia stwierdzam, ze sie mylisz. Proponuje gleboka lekture oraz 
> case
> study czegos co sie nazywa concept traits. Szczególnie wazne pytania
> zadawane kompilatorowi moga byc z serii has_something<T> w polaczeniu z
> IF_<S,T,U>. To jest naprawde cenne w przypadku bardzo restrykcyjnych
> kontraktów na klasy parametryzujace szablony.

boost::mpl-a powinno sie zabronic uzywac a traity sa ciagle w C++ w 
powijakach
czyli nie do uzycia.

AK

Witam

Adam Karpierz wrote:

> Dlatego chocby nie wiem co sie dzialo to C++ templates w swej istocie
> zawsze pozostana czyms w rodzaju makrogeneratora.

Dlatego zadałem zadanie dla spejalistów od makrogeneracji, aby napisali
operator skałdania dwóch dowolnych funkcji dwuargumentowych i nikt nie
zawalczył, czyli, albo to jest kit z tym makrogeneratorem, albo koś tu jest
cieńki z programowania. Tak na maginesie to w ten sposób wszystkie jezyki
funkcyjne można określić jako języki z makrogeneratorami, bo co innego robi
Haskel czy Lisp jak właśnie nie rozwija wyrażeń - ot taka sobie
makrogeneracja. A wyrażenia typu "lambda (x)" w Pythonie to korzystanie z 
makrogeneracji?

Pozdrawiam.

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

Witam

Adam Karpierz wrote:

> boost::mpl-a powinno sie zabronic uzywac

Może. To jest opinia nie podparta żadnym argumentem, więc traktuje ją jako
lakoniczną.

> a traity sa ciagle w C++ w powijakach czyli nie do uzycia.

Jak ktoś nie umie, to niech nie używa. Używam i uważam, że czasem są
konieczne i często potrzebne. Zresztą w Javie też można zadawać niektóre z
pytan, które sa możliwe w C++. Javiści to używają więc czemu w C++ to jest
złe. Wszczególności piekne są pytania o dziedziczenie np. : Foo < ? extends
Bar >, które jest pytaniem czy klasa ? podstawiana do generyka jest
podklasą Bar. Bardzo dobre pytanie, w szczególności przy własności
"erasure" mając w środku generyka klasę mamy prewność jej API. To samo w
C++ można zadać stosując boost::is_base< pytajnik , Bar >. Jest jeszcze
cała masa zapytań. No i pięknie działający szablonowy IF < >. Z reszta
boost::pyhton jest nasiany traitsami, które pięknie tam pracują, co widać
po zgrabności pracy z boost::python.

Pozdrawiam.

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

Dnia Fri, 8 Sep 2006 11:43:40 +0200, Adam Karpierz skrobie:
> > W C++ dostajemy "szablon funkcji", z ktorego kompilator moze nam usluznie
> > wygenerowac konkretna funkcje (ale nie wygeneruje, np. kiedy napisalismy
> > specjalna wersje z reki).

> Dokladnie !.
> Dlatego chocby nie wiem co sie dzialo to C++ templates w swej istocie
> zawsze pozostana czyms w rodzaju makrogeneratora.

Ok - zdefiniuj zatem, czym jest makrogenerator. I przedstaw, jak byś napisał
makrogenerator, który generuje C z C++, gdzie używa się czegoś nawet tak
prostego, jak boost::mpl.

> Cala ich istota (a nieszczegoly implementacyjne itp) jest tak blisko
> makrogeneracji jak daleko od prawdziwego polimorfizmu parametrycznego
> (czy jak to tam nazwac).

W szzególności, są dalego _za_ polimorfizmem parametrycznym.

> PS: Sektor sie chyba rozchoruje :)

Musiałbyś trochę więcej chleba zjeść.


-- 
//  _    ___         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 Fri, 8 Sep 2006 16:35:52 +0000 (UTC), Sektor van Skijlen
<ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:

>Dnia Fri, 8 Sep 2006 11:43:40 +0200, Adam Karpierz skrobie:
>> > W C++ dostajemy "szablon funkcji", z ktorego kompilator moze nam usluznie
>> > wygenerowac konkretna funkcje (ale nie wygeneruje, np. kiedy napisalismy
>> > specjalna wersje z reki).
>
>> Dokladnie !.
>> Dlatego chocby nie wiem co sie dzialo to C++ templates w swej istocie
>> zawsze pozostana czyms w rodzaju makrogeneratora.
>
>Ok - zdefiniuj zatem, czym jest makrogenerator. I przedstaw, jak byś napisał
>makrogenerator, który generuje C z C++, gdzie używa się czegoś nawet tak
>prostego, jak boost::mpl.

Panie Sektor, a czy Pan wie co to jest "makrogenerator"?... Widzial
Pan kiedys na przyklad M4? Jak Pan nie widzial, to niech Pan
zobaczy. Kazdy UNIX ma. Cygwin tez. Otoz spiesze Panu doneisc ze
dawno temu napisalem w M4 translator jezyka do opisu rownan
rozniczkowych ktory to M4 (okolo 600 linii tegoz) translowal ow
specjalizowany jezyk do Fortranu. 

Wiec neich sie Pan douczy co to jest "makrogenerator" jak rowneiz
dowie sie ze wiekszosc z nich (M4, ML/1, GPM) jest rownowazna
Maszynie Turinga, a wiec mozna w nich robic zupelnie dowolne rzeczy.
I ze "makrogenerator" to nei oznacza automatycznei "makrogenerator
jezyka C", bo ten to rzeczywiscie nic nei moze.

A.L.

Dnia Fri, 08 Sep 2006 11:46:03 -0500, A.L. skrobie:
> On Fri, 8 Sep 2006 16:35:52 +0000 (UTC), Sektor van Skijlen
> <ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:

> >Dnia Fri, 8 Sep 2006 11:43:40 +0200, Adam Karpierz skrobie:
> >> > W C++ dostajemy "szablon funkcji", z ktorego kompilator moze nam usluznie
> >> > wygenerowac konkretna funkcje (ale nie wygeneruje, np. kiedy napisalismy
> >> > specjalna wersje z reki).
> >
> >> Dokladnie !.
> >> Dlatego chocby nie wiem co sie dzialo to C++ templates w swej istocie
> >> zawsze pozostana czyms w rodzaju makrogeneratora.
> >
> >Ok - zdefiniuj zatem, czym jest makrogenerator. I przedstaw, jak byś napisał
> >makrogenerator, który generuje C z C++, gdzie używa się czegoś nawet tak
> >prostego, jak boost::mpl.

> Panie Sektor, a czy Pan wie co to jest "makrogenerator"?... Widzial
> Pan kiedys na przyklad M4? Jak Pan nie widzial, to niech Pan
> zobaczy. Kazdy UNIX ma. Cygwin tez. Otoz spiesze Panu doneisc ze
> dawno temu napisalem w M4 translator jezyka do opisu rownan
> rozniczkowych ktory to M4 (okolo 600 linii tegoz) translowal ow
> specjalizowany jezyk do Fortranu. 

Aleś mi pan zaimponował, doprawdy!

Oczywiście, że można definiować języki i "kompilatory" do nich w postaci
definicji dla makrogeneratora M4 - choć moim skromnym zdaniem znacznie
prościej DSL-e robi się w Tcl-u.

Ale to nie ma nic do tematu - napisz pan makrogenerator (albo zaproponuj pan,
jak to napisać), który "rozwinie" wzorce w C++, to wtedy będziemy wiedzieli, o
czym rozmawiamy.

> Wiec neich sie Pan douczy co to jest "makrogenerator" jak rowneiz
> dowie sie ze wiekszosc z nich (M4, ML/1, GPM) jest rownowazna
> Maszynie Turinga, a wiec mozna w nich robic zupelnie dowolne rzeczy.

To wciąż o niczym nie świadczy.

Makrogenerator, który rozwija się w specjalizacje to można sobie do Javy
napisać. 

> I ze "makrogenerator" to nei oznacza automatycznei "makrogenerator
> jezyka C", bo ten to rzeczywiscie nic nei moze.

Ojejejejejej...

Panie Andrzeju, wszystkich rozumów jeszcze pan na szczęście nie zjadłeś, a
znaojomość sposobu konkretyzacji wzorców zajmuje wśród nich chlubną pozycję.

Mała kwestia do rozważenia:

Załóżmy, że mamy klasę: template<class T1, class T2> class is_same_type ...

Jeśli napiszę np.:

is_same_type<int,float>::value

czy to znaczy, że od tej pory istnieje klasa is_same_type<int,float> ?


-- 
//  _    ___         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"