🚀 go-pugleaf

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

> 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.

> 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.

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

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

pozdrawiam,
Przemek O.