🚀 go-pugleaf

Dnia 10-03-2007, sob o godzinie 18:47 +0000, Sektor van Skijlen
napisał(a):

> > Jest jeszcze trzecia kategoria leżąca pomiędzy tymi dwiema:
> > wskaźniki na singletony, czyli na jedyne obiekty danego rodzaju,
> > np. true / false / nil. Te obiekty są niezmienialne, ale tożsamość
> > tych obiektów jest dobrze zdefiniowana; rozróżnianie ich po tożsamości
> > jest równoważne rozróżnianiu po cechach wewnętrznych.
> 
> Nie tworzyłbym specjalnej kategorii dla tych obiektów.

Zwykle można je traktować razem z wartościowymi. Różnica objawia
się tylko wtedy, kiedy w języku mamy do dyspozycji operację jawnie
porównującą dwa obiekty po tożsamości. Tę operację można uznać za
niskopoziomową i rzadko się jej wprost używa, ale w wielu językach
jest dostępna, bo może być tańsza od domyślnego porównania, a dla
pewnego zbioru obiektów jest mu równoważna (Lisp: EQ, Scheme: eq?,
Python: is, Kogut: Is, OCaml: ==). Na przykład w Pythonie porównanie
"x is None" jest praktyczne, a "x is 5" nie jest.

> > Jeśli spróbować dopasować do tego modelu C++, to się okaże, że zmienną
> > C++ zawierającą obiekt można rozumieć na dwa sposoby:
> 
> > a) Jako zmienialny obiekt, przywiązany na stałe do swojej nazwy.
> >    To tłumaczenie jest odpowiednie w przypadku obiektów z tożsamością,
> >    zwłaszcza złożonych, bo pozwala wymodelować możliwość zmiany
> >    indywidualnych pól obiektu z zachowaniem tożsamości całego obiektu.
> >    Takie obiekty są zwykle przekazywane przez referencje C++ albo
> >    wskaźniki C++, co odpowiada przekazaniu wskaźnika na obiekt
> >    w modelu, a więc odpowiada naturalnemu sposobowi przekazania
> >    wartości w modelu.
> 
> > b) Jako zmienną zawierającą wartość, która sama jest niezmienialna.
> >    To tłumaczenie jest lepsze dla atomowych typów wartościowych,
> >    bo pozwala wymodelować wartość wyabstrahowaną od miejsca
> >    przechowywania. Takie obiekty są w C++ zwykle kopiowane,
> >    co odpowiada przekazaniu odczytanej bieżącej wartości zmiennej
> >    w modelu, czyli znowu jest naturalnym sposobem przekazania wartości,
> >    mimo że w C++ jest inne niż tamto.
> 
> Szczerze mówiąc to nic z tego nie rozumiem.

Bo opisałem odpowiedniki zmiennej w C++ językiem (ludzkim)
przystosowanym do opisywania innych języków (programowania).
Jesteś przyzwyczajony do języka (ludzkiego) przystosowanego
do opisywania C++.

Jeśli w C++ mamy zmienną zawierającą obiekt udostępniający jakieś metody
(w tym metody zmieniające jego stan), to w innym języku odpowiednik tej
konstrukcji wygląda z reguły na jeden z dwóch sposobów, zależnie od
stylu, w jakim przeważnie wygodnie jest używać obiektów danego typu:

a) Typowy przykład: tablica.

   Zmienna wskazuje na obiekt udostępniający analogiczne operacje jak
   w C++. Obiekt jest tworzony na stercie. Do tej zmiennej nie jest
   nigdy przypisywany wskaźnik na inny obiekt.

   Tam, gdzie w C++ obiekt jest przekazywany przez referencję, w innym
   języku przekazywana jest wartość tej zmiennej (wskazująca na ten
   obiekt). Tam, gdzie w C++ obiekt jest przekazywany przez wartość,
   w innym języku obiekt jest klonowany (czymś w rodzaju metody Clone).

b) Typowy przykład: liczba.

   Zmienna wskazuje na niezmienialny obiekt innego języka reprezentujący
   bieżący stan obiektu C++. Metodom C++, które zmieniały stan obiektu,
   odpowiadają operacje zwracające nowy obiekt, który jest przypisywany
   z powrotem tej zmiennej.

   Tam, gdzie w C++ obiekt jest przekazywany przez wartość, w innym
   języku przekazywana jest bieżąca wartość zmiennej. Tam, gdzie
   w C++ obiekt jest przekazywany przez referencję, w innym języku
   przekazywana jest referencja na zmienną.

> String zawsze powinien być traktowany jak wartość, natomiast wektor zawsze
> jak obiekt.

Zgodzę się, że zazwyczaj. Nie zgadzam się, że zawsze.

A wektor znaków? Z jednej strony to jest wektor. Z drugiej strony to
jest w zasadzie to samo, co string. Różnice są w dodatkowych metodach,
ale one są raczej poboczne, nie wpływają na istotę rzeczy.

> > Pisałem tutaj o zmienialnym stringu, zakładając, że to jest jedyny
> > string w danym języku. Czyli kiedy złożony typ pełniący rolę typu
> > wartościowego jest jednak zmienialny. Taka sytuacja jest kłopotliwa.
> 
> Oj... nie bardzo to widzę.

No i właśnie mówię, że to jest kłopotliwe. Lepiej tego unikać.

W to C++ pasuje. W Perlu też; to jest jeden z nielicznych języków
(obok Pascala, C i C++), który kopiuje zawartość stringa przy
przypisaniu, choć przy przekazaniu jako argument funkcji formalnie
już nie (ale w praktyce zwykle tak, bo większość funkcji zaczyna się
od skopiowania argumentów do osobnych lokalnych zmiennych - specyfika
Perla).

Przykłady języków, które mają wyłącznie zmienialne stringi mimo
paradygmatu, który do tego nie pasuje: Lisp, Scheme, OCaml, Ruby
(czasem są zmienialne łącznie ze zmianą długości, a czasem nie).

> > Mój model w wersji czystej wymaga zdecydowania się, który styl użycia
> > jest tutaj dominujący. Pomieszanie styli grozi błędami aliasowania albo
> > niepotrzebnymi kopiami.
> 
> No właśnie - ale nie możesz zrobić tak, że w całym języku jeden model
> obowiązuje wszystkie obiekty.

Oczywiście, tego nie proponowałem. Byle był ustalony styl dla danego
typu.

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