W dniu 2019-09-07 o 16:12, Roman Tyczka pisze:

>
>> Jeśli nie PHP, to może C#. Jeśli miałbym tworzyć standardy, to z
>> pewnością powieliłbym zachowanie się prywatnych zmiennych z tego
>> typu języków.
>
> To, że w jakichś językach jest to tak czy inaczej nie jest dowodem,
> że tak powinno być.

Chwila, ale nie rozmawiamy tu o postępowaniu sądowym, czy rozkminianiu
zagadek matematycznych by o jakichś dowodach wspominać.

Jeśli chcesz bawić się w dowody zachowania się zmiennych prywatnych w
JS, to z natury rzeczy stoisz na przegranej pozycji, bo czegoś takiego w
JS nie ma ... przynajmniej do momentu gdy zastosujemy sztuczek, jakie
opisałem. Wtedy można je wykrzesać nawet w natywnym JS i zachowują się
one dokładnie tak samo jak w innych językach.

Jeśli natomiast mówimy o zachowaniu się zmiennych prywatnych w TS to
może warto wrócić do podstaw i przeczytać definicję zmiennej prywatne.
Jej definicja jest jedna i wspólna dla wszystkich języków:

https://pl.wikipedia.org/wiki/Zmienna_prywatna

lub tu:

https://pl.wikipedia.org/wiki/Zmienna_(informatyka)

"Zmienne zadeklarowane w module mogą być zmiennymi prywatnymi modułu -
dostępnymi wyłącznie z jego wnętrza - lub zmiennymi publicznymi
(eksportowanymi) - dostępnymi tam, gdzie moduł jest wykorzystywany.
Podobnie jest ze zmiennymi w klasie - mogą być dostępne:
tylko dla danej klasy (zmienna prywatna),"

https://www.p-programowanie.pl/cpp/klasy-c/

"private - dostęp do składników klasy jest zabroniony z poza ciała klasy"

Nie chcę już cytować linków na ten sam temat w kontekście PHP czy Java.
Sposób zachowania zmiennych prywatnych jest tam również zgodny z definicją.

TS łamie tą definicję. Zdefiniowana przez niego zmienna prywatna w
klasie, w kodzie wynikowym będzie podlegać nadpisywaniu przez klasę
potomną. Owszem, powstanie podczas transkompilacji absurdalny błąd,
który nie ma prawa zaistnieć, a wadliwy kod wynikowy i tak wygeneruje się.

> Źródłem są przemyślenia. Oto mój tok rozumowania: Tworzysz obiekt
> klasy Test2. Klasa Test2 ma prywatne pole ukryte pod this._message.
> Wołasz z tego obiektu metodę, która zwraca this._message. Skoro jest
> to obiekt klasy Test2 to dla tego typu this._message jest czymś innym
> niż dla typy Test, prawda? Dla mnie to sprawa oczywista jak
> oddychanie ;-) Jest tu wyraźna niejednoznaczność i punkt sporny,
> który warto wywalić na twarz chociażby ostrzeżeniem.
>
> To, że Java czy C# zwraca bezrefleksyjnie (czy są jakieś ostrzeżenia
> kompilatora?) wcale nie jest fajne, bo łatwo o masę głupich błędów,
> które transpiler TS wyłapuje jak zeznałeś. Mnie to bardzo cieszy, bo
> nie uważam, że taka praktyka jak identyczna nazwa prywatnego pola w
> dziedziczeniu to dobra praktyka. Ot wszystko.
>

Hmmm... wydaje mi się, że taki sposób rozumowania i obawy o to, co jak
mają się zachowywać zmienne prywatne (niezależnie od języka
programowania) wynikają z Twojego niezrozumienia czym w ogóle są zmienne
prywatne. Zapewniam Cię, że ani w C ani w PHP obecność zmiennej
prywatnej w klasie bazowej nie będzie podlegać nadpisaniu w klasie
potomnej bo to są dwa oddzielne byty w dwóch różnych obszarach RAM.
Żadne ostrzeżenia o używaniu zmiennych prywatnych w obu klasach nie
powstaną w trakcie kompilacji C lub używania PHP bo ... nie ma o czym
ostrzegać. Nie ma w tym żadnego błędu jak i obie zmienne nie będą w
konflikcie. Jedynie TS się wyłamuje i nadużywa terminu prywatności.
Przypuszczam, że jest to zwyczajny błąd twórców TS.

Spytam jeszcze: czy Ty w ogóle programujesz z użyciem OOP? Masz
wątpliwości co do najbardziej podstawowych pojęć w tej technice.

--
Pozdrawiam,
Marek