🚀 go-pugleaf

On 2008-06-13, ZB wrote:
> Sądzę, że wartałoby ten rozdział uzupełnić jasnym stwierdzeniem, że te
> "przestrzenie nazw" to tak naprawdę jeden wielki pic, i że (prawie) równie
> dobrze działałoby po prostu wydłużanie nazw procedur/zmiennych odpowiednimi
> przedrostkami, np. zamiast ::moja_przestrzen::puts może być równie dobrze:
> __moja_przestrzen__puts - i mamy z grubsza to samo: nazwę procedury, która
> nie koliduje ze "standardowym" puts.
Taki jest też cel przestrzeni nazw w dowolnym języku...

-- 
Damian Szuberski

Dnia 13.06.2008 Damian 'legion' Szuberski <legion@wmid.cutthisjunk.amu.edu.andthis.pl> napisał/a:

> Taki jest też cel przestrzeni nazw w dowolnym języku...

E, tam: to po co takie "fachowe nazwy" na zwyczajne przedrostki.
-- 
ZB

On 14.06.2008, ZB <zbREMOVE_THIS@AND_THISispid.com.pl> wrote:
> Dnia 13.06.2008 Damian 'legion' Szuberski <legion@wmid.cutthisjunk.amu.edu.andthis.pl> napisał/a:
>
>> Taki jest też cel przestrzeni nazw w dowolnym języku...
>
> E, tam: to po co takie "fachowe nazwy" na zwyczajne przedrostki.

Bo do tego służą. Pokaż mi dowolny inny język, w którym przestrzenie
nazw działają inaczej.

-- 
Secunia non olet.
Stanislaw Klekot

On 2008-06-14, ZB wrote:
>> Taki jest też cel przestrzeni nazw w dowolnym języku...
> E, tam: to po co takie "fachowe nazwy" na zwyczajne przedrostki.
Dla wygody. Zmieniasz przestrzeń nazw to edytujesz 1 linijkę a nie
poprawiasz nazw wszystkich klas.

-- 
Damian Szuberski

Dnia 14.06.2008 Stachu 'Dozzie' K. <dozzie@dynamit.im.pwr.wroc.pl.nospam> napisał/a:

>>> Taki jest też cel przestrzeni nazw w dowolnym języku...
>>
>> E, tam: to po co takie "fachowe nazwy" na zwyczajne przedrostki.
>
> Bo do tego służą.

No jasne: po co mówić "spodnie" - skoro można mówić "ineksprymable". Oznacza
dokładnie to samo - za to jak brzmi! Od razu taki dyskutant, używający
"fachowego słownictwa" zyskuje na autorytecie.  :]

> Pokaż mi dowolny inny język, w którym przestrzenie nazw działają inaczej.

Mnie nie interesuje "dowolny inny język" - bo najwidoczniej nie jestem takim
"omnibusem-językoznawcą" jak co poniektórzy tutaj.

Po prostu uznałem, że w tutorialu - przeznaczobym chyba z założenia dla
poznających dopiero TCL - warto przedstawić sprawy takimi, jakimi się w
istocie mają, choćby po to, żeby ułatwić zrozumienie im, jak to właściwie
działa, zamiast budować "mistyczną aurę wtajemniczenia". Tyle w tym temacie.
-- 
ZB

Dnia 14.06.2008 Damian 'legion' Szuberski <legion@wmid.cutthisjunk.amu.edu.andthis.pl> napisał/a:

>>> Taki jest też cel przestrzeni nazw w dowolnym języku...
>> E, tam: to po co takie "fachowe nazwy" na zwyczajne przedrostki.
> Dla wygody. Zmieniasz przestrzeń nazw to edytujesz 1 linijkę a nie
> poprawiasz nazw wszystkich klas.

Nie pytałem: "po co się to robi", tylko: "po co to mętniactwo w
nazewnictwie" ("przestrzenie nazw" - faktycznie, "big deal", można byłoby
mniemać).

Aha, już wiem: "dla wygody". Dzięki.
-- 
ZB

ZB wrote:

> Oczywiście, trochę upraszczam - ale przecież naprawdę tylko trochę... taki
> kawał miejsca jest temu poświęcony w manualu - a to w sumie sprowadza się
> jedynie do wydłużenia nazw procedur/zmiennych, które przecież w efekcie
> wszyściutkie - co do jednej - i tak znajdują się w "przestrzeni
> globalnej". A zatem odróżniane są jedynie po przeraźliwie długiej nazwie.
> Wszystkie te "namespace eval" to tylko "chwilowe zezwolenie" na
> posługiwanie się nazwą bez przedrostka, bo jakiś automat go doda "w
> imieniu użytkownika".

Nie do końca. Z resztą tak jak napisałeś - upraszczasz. Właśnie ta
właściwość NS'ów, że można wykonywać kod w [namespace eval] czyni ją
wygodniejszą od prefixów (co z resztą napisał już w tym wątku Legion). Do
tego masz importowanie całego NS'a - czyli można się szybko
pozbyć "prefixów". Chodzi o porządek. Dzięki NSom tworzony kod jest lepszej
jakości.

Jeśli post dotyczy mojego tutoriala (tak wnioskuję po opisie), to przyznaję
że niepotrzebnie zaciemniłem opis NSów, dodam sobie do TODO, żeby uprościć
język.

-- 
Pozdrawiam! (Regards!)
Googie

Dnia 16.06.2008 Googie <no@spam.0rg> napisał/a:

> Nie do końca.

...no nie do końca - ale jednak nawet moi adwersarze byli łaskawi się
zgodzić, że do tego wreszcie, w efekcie, to się sprowadza. Szukając sobie
przykładów "z innej beczki" - trafiłem na to, i tak jakoś mi się nasunęło,
że w sumie warto byłoby to podkreślić.

Ja po prostu uważam, że takie otwarte "podanie kawy na ławę" komuś
czytającemu tutorial ułatwi zrozumienie, "o co w tym właściwie chodzi". Otóż
jak się to zrozumie, to okazuje się, że nic takiego znowuż niesamowitego.

Według mnie, to powinno być wyraźnie napisane na stronach oryginalnego
podręcznika - nie to, że w tutorialach.
-- 
ZB

NS to jednak o wiele więcej niż przedrostki.
Na NS bazuje kilka systemów objektowych. Między innymi XOTcl i chyba
ITcl.
Funkcja "variable" potrzebuje NS.
"::zmiena" także możne zastąpić użycie "global".
W Tcl NS można używać w pełni dynamicznie. W jakim innym języku jest
to jeszcze możliwe?

Oczywiście dla małych programików NS są niepotrzebne i Tcl długo lat
dawał sobie bez nich rady.
Służą najlepiej przy tworzeniu ogólnych bibliotek i "framework"ów.

Artur

Dnia 23.06.2008 Artur <mail@xdobry.de> napisał/a:

> NS to jednak o wiele więcej niż przedrostki.
> Na NS bazuje kilka systemów objektowych. Między innymi XOTcl i chyba
> ITcl.
> Funkcja "variable" potrzebuje NS.
> "::zmiena" także możne zastąpić użycie "global".

...bo akurat tak to wszystko zrobiono - "z tego, co było pod ręką". To nie
jest wskazanie na to, że bez NS w takim wydaniu, jakie widzimy, nie dałoby
się absolutnie tych rzeczy zrealizować.

> W Tcl NS można używać w pełni dynamicznie. W jakim innym języku jest
> to jeszcze możliwe?

Nie wiem. Trzeba byłoby zrobić przegląd tych wszystkich języków - tylko,
tak właściwie, po co? Dla wykazania się w dyskusji?


TCL ma wiele zalet - ale i ma swoje nieco niewygodne strony: np.
terminologię opracowaną chyba specjalnie "dla zmylenia przeciwnika" :]
- zwłaszcza takiego, który dopiero się do tego zabiera, a w międzyczasie
już czegoś innego zdążył "liznąć".

Funkcje nazwano procedurami, arraye jednowymiarowe - listami, wskaźniki
(chyba jedynie dla odmiany) - arrayami (przyporządkowującymi), a skoro
ta nazwa została już użyta, to prawdziwe arraye asocjacyjne trzeba było
nazwać... słownikami (chociaż to nazwa myląca - bo słownik działa przecież
W OBIE strony), sama zasada "kiedy termin jest skrócony, a kiedy użyty w
całości" też stosowana jest bez jakiejś wyraźnej logiki: "channel"
skrócono do "chan" (naprawdę byłoby za długie?), ale już "continue" jest
w całości, chociaż w paru językach egzystuje sobie jako "cont"... tak trochę
"zróbmy to koniecznie inaczej" wymyślono (a przynajmniej: inaczej to sobie
nazwijmy). Przy czym z tego "inaczej" wcale nie ma widocznych korzyści.
Osobiście przypuszczam, że to jest raczej przeszkodą w szerszym
upowszechnieniu.

No dobra, poczepiałem się trochę... w sumie niby można z tym żyć.
-- 
ZB