Re: Carnegie-Mellon przestaje uczyc programowania obiektowego

eGospodarka.pl › Grupy › pl.comp.programming › Carnegie-Mellon przestaje uczyc programowania obiektowego › Re: Carnegie-Mellon przestaje uczyc programowania obiektowego

Path: news-archive.icm.edu.pl!news.gazeta.pl!newsfeed.pionier.net.pl!news.glorb.com!p
ostnews.google.com!v16g2000vbq.googlegroups.com!not-for-mail
From: Maciej Sobczak <s...@g...com>
Newsgroups: pl.comp.programming
Subject: Re: Carnegie-Mellon przestaje uczyc programowania obiektowego
Date: Mon, 4 Apr 2011 05:37:34 -0700 (PDT)
Organization: http://groups.google.com
Lines: 57
Message-ID: <0...@v...googlegroups.com>
References: <1...@4...com>
<4d9232b8$0$2487$65785112@news.neostrada.pl>
<o...@4...com>
<h...@4...com> <imvgi6$3p9$1@news.onet.pl>
<s...@c...tac>
<c...@4...com>
<2...@c...tac> <in5kp4$5r5$1@news.onet.pl>
<in5ua3$1kk$1@news.onet.pl> <g...@b...softax.pl>
<inc99j$gra$1@news.onet.pl>
NNTP-Posting-Host: 83.3.40.82
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
X-Trace: posting.google.com 1301920654 1494 127.0.0.1 (4 Apr 2011 12:37:34 GMT)
X-Complaints-To: g...@g...com
NNTP-Posting-Date: Mon, 4 Apr 2011 12:37:34 +0000 (UTC)
Complaints-To: g...@g...com
Injection-Info: v16g2000vbq.googlegroups.com; posting-host=83.3.40.82;
posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13)
Gecko/20101203 Firefox/3.6.13,gzip(gfe)
Xref: news-archive.icm.edu.pl pl.comp.programming:189666
[ ukryj nagłówki ]
On 4 Kwi, 13:15, Paweł Kierski <n...@p...net> wrote:

> Pomijając na razie kwestie łatwości zapisu i czytelności - nie widzę tu
> niczego, czego nie dałoby się wyrazić w C++ za pomocą przestrzeni nazw
> i jednostek kompilacji.

Ja też nie, ale tylko dlatego, że Sebastian niewiele napisał :-) -
chociaż można się przyczepić, że w C++ trzeba posługiwać się fizcznymi
aspektami kodu (podział na pliki), żeby osiągnąć jakiś cel logiczny,
np. ukrycie części prywatnej. To powinno być dostępne nawet w obrębie
jednego pliku.

Ale dodaj do tego jeszcze jakąś semantykę hierarchii i przestrzenie
nazw okazują się być zbyt ubogie. Np. relację rodzic-dziecko między
pakietami, która ma konsekwencje w widoczności nazw w jednym kierunku
(np. tylko dziecko widzi część prywatną rodzica). Albo podział na
pakiety publiczne i niepubliczne, również z konsekwencjami w
hierarchii (np. tylko rodzic może wciągać swoje niepubliczne dzieci).
Można sobie jeszcze wyobrazić różne rodzaje hierarchii - np.
zagnieżdżenie vs. rodzic-dziecko. To są dwie różne relacje i mogą być
użyte w różnych celach.

Do tego można sobie jeszcze wyobrazić, że pakiety czy moduły wcale nie
muszą być konstrukcjami top-level. Np. czemu nie mieć lokalnych
pakietów/modułów tak jak mogą być lokalne klasy czy lokalne
podprogramy? Albo czemu by pakiet/moduł nie miał być parametrem
szablonu? To by było dobre zwłaszcza przy szablonach typu traits -
teraz w C++ robi się sztuczne struktury ze statycznymi deklaracjami w
środku, żeby zebrać do kupy parę rzeczy i podać razem jako parametr;
przecież to nie powinna być struktura, to powinien być właśnie pakiet/
moduł.

Biorąc to wszystko do kupy przestrzenie nazw w C++ właściwie niczego
nie oferują, a pakiety w Javie to (jak zwykle) tzw. "half-ass
solution".

> Innymi słowy - da się pisać modułowo w C++

Da się organizować deklaracje w grupy. Np. std:: to grupa nazw z
biblioteki standardowej a yami:: to grupa nazw z YAMI4. W C do tego
samego celu stosuje się przedrostki i niestety ale to jest cała
funkcjonalność tego elementu języka. Faktem jest, że w 98% przypadków
tylko o to chodzi, ale pozostaje jeszcze te ciekawe 2%.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com