🚀 go-pugleaf

W dniu 13.11.2018 o 15:23, immo pisze:
> W dniu wtorek, 13 listopada 2018 12:09:14 UTC+1 użytkownik Roman Tyczka napisał:
>> No zaraz. Wyjaśnij co miałeś w tym wypadku na myśli? Bo skoro w C# string
>> to klasa to oczywiste jest, że ma metody. Ale przez fakt bycia klasą ma też
>> większy narzut na zasoby.
> 
> No właśnie. Ale nie dotyczy to wszystkich typów ale niektórych. I tak w przypadku stringa wolałbym, żeby domyślnie był klasą :)
Po co?
Ile razy dziedziczyłeś z typu prostego w C#?
No to ta "pełna obiektowość" nie zawsze jest potrzebna i przydatna (tak, 
tak - wiem co napisałem).

Tak czy siak, na pewno nigdy nie dziedziczyłeś ze stringa w C#, bo się 
nie da (klasa string jest sealed). Ale da się użyć dla niej Extension 
Methods, a to taki delphiowy class helper - ale lepszy ;-)

> Nie podoba mi się składniowo length(s) czy writeln(s) gdzie funkcja jest oderwana od klasy. Ot obiektowość pełna a nie częściowa :) Oczywiście to powyżej to tylko przykład jednego typu danych.
To teraz Tobie powiem - widziałeś Ty nowe Delphi?
Bo gdybyś widział, to byś wiedział że:
Length(s) = s.Length;

>> lżejszy, a dzięki helperom można go używać wygodnie jak obiektu, dla mnie
>> to zaleta nad cięższym stringiem obiektowym.
> 
> Ale trzeba je zrobić i nie ma standardu, bo każdy robi jak chce i co chce. W tym kontekście ujednolicenie ma sens taki, ze bez kombinacji i wymyślania co autor miał na myśli, domyślne działanie typu byłoby takie same.
Nie rozumiem co napisałeś.
A w C# i jego Extension Methods nie można robić co się chce i jak chce?
No można.
Jak ktoś zaprojektuje (albo i nie) API z czapy, to potem faktycznie 
trzeba się domyślać...

>> A czy nie ma sensu niczego robić? Jest, choćby te helpery rozwinąć, żeby
>> można ich było kilka naraz używać. I żeby się dało pisać helpery do
>> interfejsów. Itd.
O to, to!

> No ok, co do tego to się zgadzam. Ale helpery które dają wiele możliwości, dają też możliwość przesady i przy okazji braku jednolitości (patrz wyżej). 
> Dla mnie to byłoby wadą. 
Czyli co konkretnie?
Dostęp do sekcji i danych chronionych w klasie, o to Ci chodzi?
Nie wiem co prawda od kiedy, ale to nieaktualne.
W wersji 10.2 na pewno class helper pod kątem dostępu do metod/pól klasy 
jest równoważny z dziedziczeniem.
A więc nie ma dostępu do sekcji private, a jest dla protected, ale nie 
ma do strict protected.

> Z drugiej strony, gdyby były tak rozbudowane jak sugerujesz, to inne zmiany nie miały by sensu, bo można by sobie je samemu napisać, ze wszystkimi związanymi z tym problemami i wadami rozwiązania.
Ale co on sugeruje?
Se możesz napisać i nadpisać; w Delphi ostatni załadowany class helper 
przykrywa wszystkie wcześniejsze.
Trochę to słabe, ale od biedy można wykorzystać jak się wie co się robi.

>> Pascal był wymyślony jako jzyk edukacyjny, w takim kontekście masz rację.
>> Ale tak się (nie)szczęśliwie potoczyło, że stał się językiem produkcyjnym i
>> z tego tytułu wymagania wobec niego są zupełnie inne. Dla mnie te ficzery
>> są praktyczne. A dla przeciwników zawsze pozostaje opcja kompatybilności
> 
> Jestem otwarty na wszelkie ficzery i zmiany które niosą ze sobą wartość dodaną dla języka/środowiska, ale co do deklaracji zmiennych nie ma argumentu który by mnie do tego przekonał. Rozwiązanie wprowadziłoby niepotrzebny zamęt i zaczerniłoby, bardzo jasny do tej pory kod w Delphi.
E tam.
Można deklarować zmienne po staremu?
No można.
To używajata starej konwencji, a ja się zastanowię :)

> Jeśli by EMB zrobiło ankietę za takim rozwiązaniem, to nie jestem przekonany czy zostałoby ono wprowadzone (oczywiście pod warunkiem że osoby używające pakiet, w których interesie byłoby lub nie wprowadzenie tego ficzera oddałyby głos w tej ankiecie).
Demokracja to jest jednak najgorszy możliwy ustrój, gdzie większość "ma 
racje" ;-)

> ze
>> starą składnią, nikt nie narzuca siłą nowej. Wilk syty i owca niewydymana.
> 
> A ja Ci powiem inaczej, jeśli chcesz zmian które nie są zgodne z podstawowymi założeniami języka, to można zmienić język, ten pozostawiając go tym, którzy chcą go takiego jak jest w zakresie podstaw.
> To nie problem przenieść składnie z C# czy logikę działania. Tylko po co? Skoro jest C# sam w sobie i można go równie łatwo używać?
OK, można i tak.
A co zrobić z założeniami takiego zgnilca jak Pascal, który ma wiek 
emerytalny?
Przecież te podstawowe założenia języka była projektowane  w zupełnie 
innej rzeczywistości. Wtedy nawet internet nie istniał w podstawowych 
założeniach :D

To i ja Ci powiem inaczej - albo będziesz się rozwijał i dostosowywał, 
albo czas umierać Pascalu.

-- 
wloochacz