🚀 go-pugleaf

On Tue, 13 Nov 2018 06:23:11 -0800 (PST), immo wrote:

>> 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ą :) 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.

Tu już Ci wloochacz odpisał, zobacz Delphi od XE3 w górę.
 
>> 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.
> 
> 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ą. 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. 

Samemu lub użyć biblioteki typu Spring, która dodaje dużo dobra do RTLa.
 
>> 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

Zła forma, nie "wprowadziłoby" tylko "wprowadzi" :-) Za kilka tygodni :-)

> niepotrzebny zamęt i zaczerniłoby, bardzo jasny do tej pory kod w
> Delphi. 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). 

Społeczność delphi i Emba nie podzielają Twojwegfo zdania :-)

>> 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ć? 

Po to, żeby nie przepisywać tony swojego softu na inne środowisko a by móc
go nadal rozwijać i refaktorować w czymś nowoczesnym i bliższym wiekowi XXI
niż średniowiecznym tradycjom :-)

-- 
pozdrawiam
Roman Tyczka