🚀 go-pugleaf

W dniu 24.10.2018 o 17:50, Roman Tyczka pisze:
> 
> Co powiecie na takie rzeczy w Delphi?
> 
> begin
>   ...
>   var s : string := 'tekst';
>   for i : Integer := 1 to Length(s) do writeln(s[i]);
> 
> lub
> 
> begin
>   ...
>   var aStrList := TStringList.Create;
> 
> I jak? Dobre?
> 

Rozumiem że to przechodzi pod nową wersją. Mam wrażenie że co chwila 
nowe konstrukcje jezykowe dochodzą tylko akurat dla powyższych ciężko mi 
znaleźć uzasadnienie.

Pozdrawiam

> 
> I jak? Dobre?
> 
Ja nie widzę przeciwwskazań
M

W dniu 24.10.2018 o 23:03, J-23 pisze:
> W dniu 24.10.2018 o 17:50, Roman Tyczka pisze:
>> 
>> Co powiecie na takie rzeczy w Delphi?
>> 
>> begin ... var s : string := 'tekst'; for i : Integer := 1 to
>> Length(s) do writeln(s[i]);
>> 
>> lub
>> 
>> begin ... var aStrList := TStringList.Create;
>> 
>> I jak? Dobre?
>> 
> 
> Rozumiem że to przechodzi pod nową wersją. Mam wrażenie że co chwila
>  nowe konstrukcje jezykowe dochodzą tylko akurat dla powyższych
> ciężko mi znaleźć uzasadnienie.
> 

Czasami robię w c# i powiem szczerze, że to wygodne. Tym bardziej, że 
zasięg zmiennych mam być ograniczony do bloku, w którym zostały 
zadeklarowane.

Np. taki przypadek. Wołasz funkcję, która zwraca jakiś "dziwny" typ. 
Przy konstrukcji:
var zmienna := DziwnaFunkcja();
nie musisz dochodzić jak ten typ się dokładnie nazywa, żeby zadeklarować 
zmienną.

Tomek D.

W dniu środa, 24 października 2018 17:50:44 UTC+2 użytkownik Roman Tyczka napisał:
> Co powiecie na takie rzeczy w Delphi?
> 
> begin
>  ...
>  var s : string := 'tekst';
>  for i : Integer := 1 to Length(s) do writeln(s[i]);
> 
> lub
> 
> begin
>  ...
>  var aStrList := TStringList.Create;
> 
> I jak? Dobre?
> 
> -- 
> pozdrawiam
> Roman Tyczka

Javascript z typowaniem. Pewnie kiedyś wprowadzą 

  for i := 1 to Length(s) do writeln(s[i]);



Paweł

W dniu czwartek, 25 października 2018 08:58:51 UTC+2 użytkownik zpksoft napisał:
> W dniu środa, 24 października 2018 17:50:44 UTC+2 użytkownik Roman Tyczka napisał:
> > Co powiecie na takie rzeczy w Delphi?
> > 
> > begin
> >  ...
> >  var s : string := 'tekst';
> >  for i : Integer := 1 to Length(s) do writeln(s[i]);
> > 
> > lub
> > 
> > begin
> >  ...
> >  var aStrList := TStringList.Create;
> > 
> > I jak? Dobre?
> > 
> > -- 
> > pozdrawiam
> > Roman Tyczka
> 
 Javascript z typowaniem. Pewnie kiedyś wprowadzą 
 
   for i := 1 to Length(s) do writeln(s[i]);
 
(bez konieczności deklarowania zmiennej i) 
 
 Paweł

W dniu 25-10-2018 o 08:58, zpksoft pisze:
> W dniu środa, 24 października 2018 17:50:44 UTC+2 użytkownik Roman Tyczka napisał:
>> Co powiecie na takie rzeczy w Delphi?
>>
>> begin
>>   ...
>>   var s : string := 'tekst';
>>   for i : Integer := 1 to Length(s) do writeln(s[i]);
>>
>> lub
>>
>> begin
>>   ...
>>   var aStrList := TStringList.Create;
>>
>> I jak? Dobre?
>>
>> -- 
>> pozdrawiam
>> Roman Tyczka
> 
> Javascript z typowaniem. Pewnie kiedyś wprowadzą
> 
>    for i := 1 to Length(s) do writeln(s[i]);
>


Raczej powinni zmierzać w kierunki Go(i mam nadzieję że tak robią).

package main
import "fmt"

func main() {
     s := "Zażółć gęślą jaźń!"
     fmt.Println(s)
}

miab

W dniu środa, 24 października 2018 17:50:44 UTC+2 użytkownik Roman Tyczka napisał:
> Co powiecie na takie rzeczy w Delphi?
> 
> begin
>  ...
>  var s : string := 'tekst';
>  for i : Integer := 1 to Length(s) do writeln(s[i]);
> 
> lub
> 
> begin
>  ...
>  var aStrList := TStringList.Create;
> 
> I jak? Dobre?

Jak już wymyślamy to wolałbym

for i := 1 to s.length do s[i].toString (lub s[i].WriteLn());

A co do określania typu zmiennej to pozostałbym przy konwencji Delphi - czyli określenie typu tylko w sekcji var. Jak już dopuściłbyś w bloku kodu, to trzeba by to zrobić dla wszystkich nie tylko dla pętli a to znowu postawiłoby kod delphi na głowie, bo rodziłoby wiele dodatkowych problemów.

pozdrawiam,
Przemek O.

W dniu czwartek, 25 października 2018 09:51:09 UTC+2 użytkownik miab napisał:
> W dniu 25-10-2018 o 08:58, zpksoft pisze:
> > W dniu środa, 24 października 2018 17:50:44 UTC+2 użytkownik Roman Tyczka napisał:
> >> Co powiecie na takie rzeczy w Delphi?
> >>
> >> begin
> >>   ...
> >>   var s : string := 'tekst';
> >>   for i : Integer := 1 to Length(s) do writeln(s[i]);
> >>
> >> lub
> >>
> >> begin
> >>   ...
> >>   var aStrList := TStringList.Create;
> >>
> >> I jak? Dobre?
> >>
> >> -- 
> >> pozdrawiam
> >> Roman Tyczka
> > 
> > Javascript z typowaniem. Pewnie kiedyś wprowadzą
> > 
> >    for i := 1 to Length(s) do writeln(s[i]);
> >
> 
> 
> Raczej powinni zmierzać w kierunki Go(i mam nadzieję że tak robią).
> 
> package main
> import "fmt"
> 
> func main() {
>      s := "Zażółć gęślą jaźń!"
>      fmt.Println(s)
> }
> 
> miab

Mam nadzieję że jednak nie... :)

pozdrawiam,
Przemek O.

> A co do określania typu zmiennej to pozostałbym przy konwencji Delphi - czyli określenie typu tylko w sekcji var. Jak już dopuściłbyś w bloku kodu, to trzeba by to zrobić dla wszystkich nie tylko dla pętli a to znowu postawiłoby kod delphi na głowie, bo rodziłoby wiele dodatkowych problemów.
> 
> pozdrawiam,
> Przemek O.

Ale też uprościło by trochę kod. Gdy kod jest rozwlekły i gdzieś w środku mamy zmienną pomocniczą która pojawia się i znika w trzech linijkach kodu to po co ją deklarować w nagłówku funkcji?

Paweł

W dniu 2018-10-25 o 11:09, zpksoft pisze:
>> A co do określania typu zmiennej to pozostałbym przy konwencji Delphi - czyli określenie typu tylko w sekcji var. Jak już dopuściłbyś w bloku kodu, to trzeba by to zrobić dla wszystkich nie tylko dla pętli a to znowu postawiłoby kod delphi na głowie, bo rodziłoby wiele dodatkowych problemów.
>>
>> pozdrawiam,
>> Przemek O.
> 
> Ale też uprościło by trochę kod. Gdy kod jest rozwlekły i gdzieś w środku mamy zmienną pomocniczą która pojawia się i znika w trzech linijkach kodu to po co ją deklarować w nagłówku funkcji?


Gdy mamy taki kod, to trzeba by sie zastanowic  czy aby jest poprawnie 
napisany i nie wymaga refaktoryzacji....

-- 
http://kaczus.ppa.pl

W dniu 25-10-2018 o 11:09, zpksoft pisze:
>> A co do określania typu zmiennej to pozostałbym przy konwencji Delphi - czyli określenie typu tylko w sekcji var. Jak już dopuściłbyś w bloku kodu, to trzeba by to zrobić dla wszystkich nie tylko dla pętli a to znowu postawiłoby kod delphi na głowie, bo rodziłoby wiele dodatkowych problemów.
>>
>> pozdrawiam,
>> Przemek O.
> 
> Ale też uprościło by trochę kod. Gdy kod jest rozwlekły i gdzieś w środku mamy zmienną pomocniczą która pojawia się i znika w trzech linijkach kodu to po co ją deklarować w nagłówku funkcji?

Jak znika?

miab

> Gdy mamy taki kod, to trzeba by sie zastanowic  czy aby jest poprawnie 
> napisany i nie wymaga refaktoryzacji....
> 
> -- 
> http://kaczus.ppa.pl

To jest inny temat. Nie o tym rozmawiamy. Podałem przykład zasadności takiej zmiennej.

W dniu 2018-10-25 o 11:17, miab pisze:
> W dniu 25-10-2018 o 11:09, zpksoft pisze:
>>> A co do określania typu zmiennej to pozostałbym przy konwencji Delphi
>>> - czyli określenie typu tylko w sekcji var. Jak już dopuściłbyś w
>>> bloku kodu, to trzeba by to zrobić dla wszystkich nie tylko dla pętli
>>> a to znowu postawiłoby kod delphi na głowie, bo rodziłoby wiele
>>> dodatkowych problemów.
>>>
>>> pozdrawiam,
>>> Przemek O.
>>
>> Ale też uprościło by trochę kod. Gdy kod jest rozwlekły i gdzieś w
>> środku mamy zmienną pomocniczą która pojawia się i znika w trzech
>> linijkach kodu to po co ją deklarować w nagłówku funkcji?
>
> Jak znika?

Np na końcu bloku kodu (jakiś "end").
W innych językach nie ma z tym problemów, choćby w c#.

Pozdrawiam

> 
> Jak znika?
> 
> miab

Hehe, skrót myślowy oznaczający "nie jest dalej używana"

Paweł

W dniu 2018-10-24 o 17:50, Roman Tyczka pisze:
> Co powiecie na takie rzeczy w Delphi?

Jesteś testerem, jakieś przecieki? Wątpię żeby to zrobili ale kto wie...

Coś o nowym Delphi, jakby ktoś był ciekawy:

Przyjdź na kongres Delphi w Paryżu 15 listopada !

Robimy świetną prezentację nowej wersji RAD Studio 10.3 Rio! Kongres 
jest organizowany przez Barnstena, oficjalnego przedstawiciela 
Embarcadero we Francji. Nie jesteśmy sami ....

Tego dnia będziesz mógł poznać najnowsze osiągnięcia techniczne i 
skorzystać z porad i wskazówek przedstawionych przez ekspertów Delphi we 
Francji.

Embarcadero rozpocznie prezentację swoją najnowszą wizją, Mapą drogową, 
a następnie będzie kontynuować prezentację techniczną Rio 10.3.

Program :

9:00 - 9:30 Kawa powitalna

9:30 - 10:00 Embarcadero / Barnsten - Maxime Capellot

10:00 - 12:00 Przedstawiamy wszystkie nowe funkcje RAD Studio 10.3
Patrick Premartin (oprogramowanie Olf)

12:00 - 12:30 Prezentacja 3 aplikacji wykorzystujących najnowsze 
technologie Delphi - Maxime Capellot (Barnsten)
12:30 - 14:00 Posiłki

14:00 - 15:00 Nowa metoda RADD do tworzenia nowoczesnych aplikacji 
internetowych - Bruno Fierens (oprogramowanie TMS)

15:00 - 16:00 Nurkowanie w LiveBindings - Serge Girard

16:00 - 16:20 Przerwa dla smakoszy

16:20 - 17:20 Jak chronić swoje dane
Marion Candau (MVP Embarcadero)

Kliknij tutaj, aby zobaczyć cały program:
https://translate.googleusercontent.com/translate_c?depth=1&hl=pl&rurl=translate.google.pl&sl=auto&sp=nmt4&tl=pl&u=https://www.barnsten.com/media/wysiwyg/CAgenda141118.pdf&xid=17259,1500004,15700023,15700124,15700149,15700186,15700190,15700201,15700214,15700230&usg=ALkJrhgNct3XfvDEyPT-8sp_wqsbgTmiWA

W tym dniu będziesz miał okazję zapoznać się z zespołem Barnstena, 
ekspertami Delphi i oczywiście różnymi partnerami i deweloperami Delphi.

Czekamy na Ciebie osobiście.

Zespół Barnstena

W dniu 26.10.2018 o 16:07, Jan Drawski pisze:
> W dniu 2018-10-24 o 17:50, Roman Tyczka pisze:
>> Co powiecie na takie rzeczy w Delphi?
> 
> Jesteś testerem, jakieś przecieki? Wątpię żeby to zrobili ale kto
> wie...
> 

Przecieki z konferencji (chyba w Portugalii)
https://plus.google.com/u/0/+RafaelDipold

Dodatkowo wpis od Marco od przyszłości ARC
http://blog.marcocantu.com/blog/2018-october-Delphi-ARC-directions.html

Tomek D.

W dniu 2018-10-26 o 17:56, Tomek D pisze:
> Przecieki z konferencji (chyba w Portugalii)
> https://plus.google.com/u/0/+RafaelDipold
> 
> Dodatkowo wpis od Marco od przyszłości ARC
> http://blog.marcocantu.com/blog/2018-october-Delphi-ARC-directions.html

Dzięki, czyli jednak to się zmieniło. Dawno temu się mówiło, że dzięki 
oddzielnemu blokowi z deklaracjami jest porządek itp. Miały być same 
plusy tego. Jeszcze trochę a wymienią begin i end na klamry :)

-- 
Pozdrawiam
Janek

On Thu, 25 Oct 2018 02:01:13 -0700 (PDT), immo wrote:

>> begin
>>  ...
>>  var s : string := 'tekst';
>>  for i : Integer := 1 to Length(s) do writeln(s[i]);
>> 
>> lub
>> 
>> begin
>>  ...
>>  var aStrList := TStringList.Create;
>> 
>> I jak? Dobre?
> 
> Jak już wymyślamy to wolałbym

Nie wymyślamy tylko zaczynamy używać ;-)

> 
> for i := 1 to s.length do s[i].toString (lub s[i].WriteLn());

A co tu magicznego? Pomijając, że nie bardzo rozumiem s[i].toString to
reszta w zasadzie już jest (helpery).

> A co do określania typu zmiennej to pozostałbym przy konwencji Delphi - czyli określenie typu tylko w sekcji var. Jak już dopuściłbyś w bloku kodu, to trzeba by to zrobić dla wszystkich nie tylko dla pętli a to znowu postawiłoby kod delphi na głowie, bo rodziłoby wiele dodatkowych problemów.

Nie rodzi żadnych problemów, za to wiele ich rozwiązuje.
Dla mnie szczególnie cenne jest to, że teraz na wejściu i wyjściu z metody
nie będą wszystkie zmienne z typami zarządzalnymi (jak string, rekordy,
tablice czy interfejsy) alokowane i zwalniane, lecz tylko wtedy, gdy
wykonanie kodu wejdzie w blok, np. po staremu:

function Test(wartosc : integer) : Integer;
var
 WielkaTablica : array[milion] of Integer;
begin
 if wartosc > 10 then
 begin
  result := WielkaTablica[wartosc];
 end;
end;

Wywołanie powyższej metody powoduje, że na początku tablica jest alokowana
(4 MIB ramu!), a na końcu zwalniana, nawet jeśli jej nie tkniemy! Tak teraz
to działa, można zobaczyć w oknie ASM debugera.

Teraz, po nowemu gdy będzie tak:

function Test(wartosc : integer) : Integer;
begin
 if wartosc > 10 then
 begin
  var WielkaTablica : array[milion] of Integer;
  result := WielkaTablica[wartosc];
 end;
end;

To tylko jeśli wartosc wejściowa spełni warunek i wykonanie wejdzie w
begin/end warunku to nastąpi alokacja i zwolnienie, w innych przypadkach
nie tknie pamięci!

I teraz przełóżmy to na 10 zmiennych lokalnych, to nawet mogą być puste
stringi, nastąpi ich alokacja i zwolnienie. I teraz tak w każdej
metodzie... czujesz olbrzymią wydajnościową różnicę? Ja tak.

-- 
pozdrawiam
Roman Tyczka

> Wywołanie powyższej metody powoduje, że na początku tablica jest alokowana
> (4 MIB ramu!), a na końcu zwalniana, nawet jeśli jej nie tkniemy! Tak teraz
> to działa, można zobaczyć w oknie ASM debugera.

Od tego są tablice dynamiczne.

On Tue, 30 Oct 2018 12:22:14 +0100, Jan Drawski wrote:

>> Wywołanie powyższej metody powoduje, że na początku tablica jest alokowana
>> (4 MIB ramu!), a na końcu zwalniana, nawet jeśli jej nie tkniemy! Tak teraz
>> to działa, można zobaczyć w oknie ASM debugera.
> 
> Od tego są tablice dynamiczne.

Tak... a stringi możemy zastąpić PCharami i GetMem()... itd.

-- 
pozdrawiam
Roman Tyczka

> Tak... a stringi możemy zastąpić PCharami i GetMem()... itd.

Nie wiedziałem, że Stringi mają stałą, zadeklarowaną na początku długość :)

On Tue, 30 Oct 2018 13:46:59 +0100, Jan Drawski wrote:

>> Tak... a stringi możemy zastąpić PCharami i GetMem()... itd.
> 
> Nie wiedziałem, że Stringi mają stałą, zadeklarowaną na początku długość :)

Niestety nie pogadamy, skoro nie rozumiesz o czym mowa.

-- 
pozdrawiam
Roman Tyczka

> Dla mnie szczególnie cenne jest to, że teraz na wejściu i wyjściu z metody
> nie będą wszystkie zmienne z typami zarządzalnymi (jak string, rekordy,
> tablice czy interfejsy) alokowane i zwalniane, lecz tylko wtedy, gdy
> wykonanie kodu wejdzie w blok, np. po staremu:
>
> function Test(wartosc : integer) : Integer;
> var
>  WielkaTablica : array[milion] of Integer;
> begin
>  if wartosc > 10 then
>  begin
>   result := WielkaTablica[wartosc];
>  end;
> end;

Piszesz o typach zarządzalnych, a podajesz, jako przykład deklarację lokalnej tablicy
o stałym rozmiarze alokowaną na stosie. Nikt, o zdrowych zmysłach, nie zadeklaruje
tablicy o takim rozmiarze na stosie, a jakby się taki znalazł, to dostanie na wejściu do
tej funkcji "stack overflow".

> Wywołanie powyższej metody powoduje, że na początku tablica jest alokowana
> (4 MIB ramu!), a na końcu zwalniana, nawet jeśli jej nie tkniemy! Tak teraz
> to działa, można zobaczyć w oknie ASM debugera.
>
> Teraz, po nowemu gdy będzie tak:

> function Test(wartosc : integer) : Integer;
> begin
>  if wartosc > 10 then
>  begin
>   var WielkaTablica : array[milion] of Integer;
>   result := WielkaTablica[wartosc];
>  end;
> end;

> To tylko jeśli wartosc wejściowa spełni warunek i wykonanie wejdzie w
> begin/end warunku to nastąpi alokacja i zwolnienie, w innych przypadkach
> nie tknie pamięci!

W tym przypadku nic się nie zmieni, jeśli chodzi o miejsce i moment alokacji
pamięci dla tej konkretnej tablicy - nadal będzie rezerwowana na stosie
w momencie wejścia do funkcji Test. Ale żeby była jasność - ta tablica nie jest
zmienną zarządzalną. Podając przykład z tą tablicą tylko namieszałeś ludziom
w głowach.

> I teraz przełóżmy to na 10 zmiennych lokalnych, to nawet mogą być puste
> stringi, nastąpi ich alokacja i zwolnienie. I teraz tak w każdej
> metodzie... czujesz olbrzymią wydajnościową różnicę? Ja tak.

Wydajnościowo, to czasem może być nawet gorsze od deklarowania wszystkich
zmiennych na początku procedury/funkcji, jeśli ktoś nie wie, gdzie i kiedy są
alokowane zmienne zadeklarowane w lokalnych blokach begin end i jak często
są inicjalizowane i finalizowane (np. w pętli).

Jeśli w takim bloku begin end zadeklarujemy choć jedną zmienną zarządzalną,
to automatycznie zostanie utworzona kolejna ramka stosu, a to kosztuje
tyle samo, co utworzenie kolejnego bloku try finally end, tylko niejawnego.

Natomiast zysk wydajnościowy z używania "inlined variables" (nie wiem,
jak to przetłumaczyć na polski) jest niewielki i dotyczy jedynie prostych
operacji, których czasem może nie być, czyli ustawienia wskaźnika na nil
podczas inicjalizacji zmiennej zarządzalnej oraz sprawdzenia, czy wskaźnik
nie jest nil, przy jej finalizacji.

Zmienia się natomiast moment inicjalizacji i finalizacji tych zmiennych,
ale nic się nie zmienia, jeśli chodzi o alokację zmiennych - pamięć dla
przechowania np. nowego stringa jest nadal alokowana na stercie
w momencie przypisania wartości do zmiennej lub użycia SetLength.
Na stosie jest jedynie ustawiany wskaźnik, który pokazuje na zawartość
tego stringa utworzonego na stercie.

Taki sam lub nawet lepszy efekt wydajnościowy uzyskamy w każdej wersji
Delphi wydzielając z dużej procedury/funkcji mniejsze podprocedury, które
będą wywoływane 1 raz lub wcale, ale będą miały własne deklaracje tylko
swoich zmiennych lokalnych. No ale to przecież jest strasznie czasochłonne
dla dzisiejszych programistów ;-)

-- 
pozdrowienia
Krzysztof Szyszka, X-Files Software
Developer of X-DBGrid Component
Embarcadero Technology Partner
http://www.x-files.pl/ 

>> function Test(wartosc : integer) : Integer;
>> var
>>  WielkaTablica : array[milion] of Integer;
>> begin
>>  if wartosc > 10 then
>>  begin
>>   result := WielkaTablica[wartosc];
>>  end;
>> end;
>
> Piszesz o typach zarządzalnych, a podajesz, jako przykład deklarację 
> lokalnej tablicy
> o stałym rozmiarze alokowaną na stosie. Nikt, o zdrowych zmysłach, nie 
> zadeklaruje
> tablicy o takim rozmiarze na stosie, a jakby się taki znalazł, to 
> dostanie na wejściu do
> tej funkcji "stack overflow". 
Trochę się kolega zagalopował. Zmienna "WielkaTablica" nie będzie 
alokowana na stosie, tylko na stercie.
Niby podobnie brzmi, ale różnica jest znacząca.

> Trochę się kolega zagalopował. Zmienna "WielkaTablica" nie będzie alokowana na stosie, tylko na 
> stercie.

A jakieś uzasadnienie kolega napisze, bo chciałbym się dowiedzieć dlaczego?

-- 
pozdrowienia
Krzysztof Szyszka, X-Files Software
Developer of X-DBGrid Component
Embarcadero Technology Partner
http://www.x-files.pl/

On Tue, 30 Oct 2018 20:35:22 +0100, Krzysztof Szyszka wrote:

>> function Test(wartosc : integer) : Integer;
>> var
>>  WielkaTablica : array[milion] of Integer;
>> begin
>>  if wartosc > 10 then
>>  begin
>>   result := WielkaTablica[wartosc];
>>  end;
>> end;
> 
> Piszesz o typach zarządzalnych, a podajesz, jako przykład deklarację lokalnej tablicy
> o stałym rozmiarze alokowaną na stosie. Nikt, o zdrowych zmysłach, nie zadeklaruje
> tablicy o takim rozmiarze na stosie, a jakby się taki znalazł, to dostanie na wejściu do
> tej funkcji "stack overflow".

Masz rację co do niepraktyczności przykładu, po prostu chodziło mi o jasny
przekaz i na kolanie to napisałem, ale przyjąłem niepoprawny typ tej
tablicy, gdyby był of string to byłoby to o co chodzi. Lub rekord czy
tablica rekordów.

>> Wywołanie powyższej metody powoduje, że na początku tablica jest alokowana
>> (4 MIB ramu!), a na końcu zwalniana, nawet jeśli jej nie tkniemy! Tak teraz
>> to działa, można zobaczyć w oknie ASM debugera.
>>
>> Teraz, po nowemu gdy będzie tak:
> 
>> function Test(wartosc : integer) : Integer;
>> begin
>>  if wartosc > 10 then
>>  begin
>>   var WielkaTablica : array[milion] of Integer;
>>   result := WielkaTablica[wartosc];
>>  end;
>> end;
> 
>> To tylko jeśli wartosc wejściowa spełni warunek i wykonanie wejdzie w
>> begin/end warunku to nastąpi alokacja i zwolnienie, w innych przypadkach
>> nie tknie pamięci!
> 
> W tym przypadku nic się nie zmieni, jeśli chodzi o miejsce i moment alokacji
> pamięci dla tej konkretnej tablicy - nadal będzie rezerwowana na stosie
> w momencie wejścia do funkcji Test. Ale żeby była jasność - ta tablica nie jest
> zmienną zarządzalną. Podając przykład z tą tablicą tylko namieszałeś ludziom
> w głowach.

Zmieni się ten aspekt właśnie, alokacja będzie w chwili użycia a nie po
wejściu do procki. I to jest olbrzymia różnica, która mnie cieszy.

>> I teraz przełóżmy to na 10 zmiennych lokalnych, to nawet mogą być puste
>> stringi, nastąpi ich alokacja i zwolnienie. I teraz tak w każdej
>> metodzie... czujesz olbrzymią wydajnościową różnicę? Ja tak.
> 
> Wydajnościowo, to czasem może być nawet gorsze od deklarowania wszystkich
> zmiennych na początku procedury/funkcji, jeśli ktoś nie wie, gdzie i kiedy są
> alokowane zmienne zadeklarowane w lokalnych blokach begin end i jak często
> są inicjalizowane i finalizowane (np. w pętli).

Niewiedza zawsze będzie przyczyną problemów, ale nie o tym mowa, nie na tym
się skupiajmy.

> Jeśli w takim bloku begin end zadeklarujemy choć jedną zmienną zarządzalną,
> to automatycznie zostanie utworzona kolejna ramka stosu, a to kosztuje
> tyle samo, co utworzenie kolejnego bloku try finally end, tylko niejawnego.
 
> Natomiast zysk wydajnościowy z używania "inlined variables" (nie wiem,
> jak to przetłumaczyć na polski) jest niewielki i dotyczy jedynie prostych
> operacji, których czasem może nie być, czyli ustawienia wskaźnika na nil
> podczas inicjalizacji zmiennej zarządzalnej oraz sprawdzenia, czy wskaźnik
> nie jest nil, przy jej finalizacji.

Moje odczucia okazuje się nie są całkiem samotne:

https://blog.grijjy.com/2018/11/02/inline-variables-can-increase-performance/

-- 
pozdrawiam
Roman Tyczka

> >> function Test(wartosc : integer) : Integer;
> >> var
> >>  WielkaTablica : array[milion] of Integer;
> >> begin
> >>  if wartosc > 10 then
> >>  begin
> >>   result := WielkaTablica[wartosc];
> >>  end;
> >> end;
> >
> > Piszesz o typach zarządzalnych, a podajesz, jako przykład deklarację lokalnej tablicy
> > o stałym rozmiarze alokowaną na stosie. Nikt, o zdrowych zmysłach, nie zadeklaruje
> > tablicy o takim rozmiarze na stosie, a jakby się taki znalazł, to dostanie na wejściu do
> > tej funkcji "stack overflow".
>
> Masz rację co do niepraktyczności przykładu, po prostu chodziło mi o jasny
> przekaz i na kolanie to napisałem, ale przyjąłem niepoprawny typ tej
> tablicy, gdyby był of string to byłoby to o co chodzi. Lub rekord czy
> tablica rekordów.

Wystarczyło zadeklarować tablicę dynamiczną jako WielkaTablica: array of Integer,
ale wtedy nie mógłbyś pisać o niepotrzebnej alokacji 4 MB RAMu, bo taka deklaracja
powoduje jedynie powiększenie ramki stosu przy wejściu do tej funkcji o 4 bajty!

Te dodatkowe 4 bajty na stosie zajmuje referencja do WielkiejTablicy, której jeszcze
nie ma i zostanie utworzona (lub nie) dopiero w kodzie funkcji przy użyciu SetLength.
Ale przy wejściu do funkcji ta referencja musi być ustawiona na Nil, żeby przy wyjściu
z funkcji nie zawierała śmieci, jeśli nie dojdzie do alokacji tablicy przez SetLength.

> >> Wywołanie powyższej metody powoduje, że na początku tablica jest alokowana
> >> (4 MIB ramu!), a na końcu zwalniana, nawet jeśli jej nie tkniemy! Tak teraz
> >> to działa, można zobaczyć w oknie ASM debugera.
> >>
> >> Teraz, po nowemu gdy będzie tak:
> >
> >> function Test(wartosc : integer) : Integer;
> >> begin
> >>  if wartosc > 10 then
> >>  begin
> >>   var WielkaTablica : array[milion] of Integer;
> >>   result := WielkaTablica[wartosc];
> >>  end;
> >> end;
> >
> >> To tylko jeśli wartosc wejściowa spełni warunek i wykonanie wejdzie w
> >> begin/end warunku to nastąpi alokacja i zwolnienie, w innych przypadkach
> >> nie tknie pamięci!
> >
> > W tym przypadku nic się nie zmieni, jeśli chodzi o miejsce i moment alokacji
> > pamięci dla tej konkretnej tablicy - nadal będzie rezerwowana na stosie
> > w momencie wejścia do funkcji Test. Ale żeby była jasność - ta tablica nie jest
> > zmienną zarządzalną. Podając przykład z tą tablicą tylko namieszałeś ludziom
> > w głowach.
>
> Zmieni się ten aspekt właśnie, alokacja będzie w chwili użycia a nie po
> wejściu do procki. I to jest olbrzymia różnica, która mnie cieszy.

No właśnie nie rozróżniasz dwóch pojęć: czym innym jest alokacja (przydział
pamięci), a czym innym inicjalizacja (ustawienie wartości początkowej dla
referencji). W tym drugim przypadku nic się nie zmieni w kwestii alokacji
pamięci. Nadal przy wejściu do funkcji zostaną zarezerwowane 4 bajty na
referencję do WielkaTablica, ale nie zostaną zainicjalizowane wartością Nil.

Inicjalizacja (i finalizacja) tej referencji nastąpi dopiero wtedy, gdy program
wejdzie do bloku warunkowego. Jeśli nie wejdzie, to referencja nie będzie
ani inicjalizowana, ani finalizowana i dlatego mówi się, że ta zmienna poza
tym blokiem nie istnieje (choć ma przydzielone 4 bajty na stosie).

> >> I teraz przełóżmy to na 10 zmiennych lokalnych, to nawet mogą być puste
> >> stringi, nastąpi ich alokacja i zwolnienie. I teraz tak w każdej
> >> metodzie... czujesz olbrzymią wydajnościową różnicę? Ja tak.
> >
> > Wydajnościowo, to czasem może być nawet gorsze od deklarowania wszystkich
> > zmiennych na początku procedury/funkcji, jeśli ktoś nie wie, gdzie i kiedy są
> > alokowane zmienne zadeklarowane w lokalnych blokach begin end i jak często
> > są inicjalizowane i finalizowane (np. w pętli).
>
> Niewiedza zawsze będzie przyczyną problemów, ale nie o tym mowa, nie na tym
> się skupiajmy.

Ale właśnie niewiedza jest przyczyną Twojej błędnej interpretacji wprowadzonych
Inlined Varaibles i Twojego huraoptymizmu ;-)

> > Jeśli w takim bloku begin end zadeklarujemy choć jedną zmienną zarządzalną,
> > to automatycznie zostanie utworzona kolejna ramka stosu, a to kosztuje
> > tyle samo, co utworzenie kolejnego bloku try finally end, tylko niejawnego.
>
> > Natomiast zysk wydajnościowy z używania "inlined variables" (nie wiem,
> > jak to przetłumaczyć na polski) jest niewielki i dotyczy jedynie prostych
> > operacji, których czasem może nie być, czyli ustawienia wskaźnika na nil
> > podczas inicjalizacji zmiennej zarządzalnej oraz sprawdzenia, czy wskaźnik
> > nie jest nil, przy jej finalizacji.
>
> Moje odczucia okazuje się nie są całkiem samotne:
>
> https://blog.grijjy.com/2018/11/02/inline-variables-can-increase-performance/

A ten przykład podany przez Erika bardzo dobrze pokazuje różnice pomiędzy
TestLocalVars i TestInlinedVars. Tylko, że Erik nie wprowadza ludzi w błąd i
nie pisze o zmianach w alokacji zmiennych, tak jak Ty to rozumiesz, ale jasno
wskazuje na różnice dotyczące miejsca inicjalizacji i finalizacji zmiennych.

"Now, the initialization and finalization code is only executed if necessary.
This improves performance, especially of ACondition is usually False."

A na koniec Eric przestrzega przed tym samym, na co ja zwróciłem uwagę,
a Ty skwitowałeś to tekstem "nie o tym mowa, nie na tym się skupiajmy".

"Currently, inline variables can increase the size of the generated code,
especially if they are of a managed type. This extra code also makes inline
managed variables not as efficient as they could be. But then again, this is
version 1.0 of this feature, so we could see improvements in the future."

-- 
pozdrowienia
Krzysztof Szyszka, X-Files Software
Developer of X-DBGrid Component
Embarcadero Technology Partner
http://www.x-files.pl/ 

>> Trochę się kolega zagalopował. Zmienna "WielkaTablica" nie będzie 
>> alokowana na stosie, tylko na stercie.
>
> A jakieś uzasadnienie kolega napisze, bo chciałbym się dowiedzieć 
> dlaczego?
>
Sorry, to ja się zagalopowałem: przeoczyłem w deklaracji "[milion]"

W dniu wtorek, 30 października 2018 12:13:28 UTC+1 użytkownik Roman Tyczka napisał:

> > for i := 1 to s.length do s[i].toString (lub s[i].WriteLn());
> 
> A co tu magicznego? Pomijając, że nie bardzo rozumiem s[i].toString to
> reszta w zasadzie już jest (helpery).

A miałeś do czynienia np. z C#?
Zresztą, jeśli podchodzisz do tego w ten sposób, że reszta w zasadzie jest (czytaj helpery) to nie ma sensu niczego robić, bo w zasadzie wszystko jest.
Natomiast deklaracji w dowolnym miejscu jestem i będę przeciwny, bo deklaracja w sekcji var jest niejako znakiem rozpoznawczym języków z rodziny Pascala i wprowadza ład i porządek w kodzie, którego nie uświadczysz w innych językach. 
To jest nadal dobre rozwiązanie.
I nie przemawia do mnie fakt, że coś gdzieś używasz raz po środku. Jeśli nie potrafisz tego znaleźć w kodzie, to znaczy że kod jest a) za długi, b) źle napisany.

Deklaracja w dowolnym miejscu zmiennych rodziłaby potrzebę istnienia garbage collectora, a powstanie tego zmarginalizowałoby potrzebę zwalniania zmiennych. I w tym momencie dostajemy potworka który byłby zależny od systemu zwalniania pamięci... Nie tędy droga IMHO.

> function Test(wartosc : integer) : Integer;
> var
>  WielkaTablica : array[milion] of Integer;

Ta... racja... Głupoty programisty nie zniwelujesz żadnymi zmianami w kompilatorze/języku.

pozdrawiam,
Przemek O.

On Tue, 13 Nov 2018 01:08:15 -0800 (PST), immo wrote:

>>> for i := 1 to s.length do s[i].toString (lub s[i].WriteLn());
>> 
>> A co tu magicznego? Pomijając, że nie bardzo rozumiem s[i].toString to
>> reszta w zasadzie już jest (helpery).
> 
> A miałeś do czynienia np. z C#?
> Zresztą, jeśli podchodzisz do tego w ten sposób, że reszta w zasadzie jest (czytaj helpery) to nie ma sensu niczego robić, bo w zasadzie wszystko jest.

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. String delphiowy nie jest klasą, jest dużo
lżejszy, a dzięki helperom można go używać wygodnie jak obiektu, dla mnie
to zaleta nad cięższym stringiem obiektowym.
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.

> Natomiast deklaracji w dowolnym miejscu jestem i będę przeciwny, bo deklaracja w sekcji var jest niejako znakiem rozpoznawczym języków z rodziny Pascala i wprowadza ład i porządek w kodzie, którego nie uświadczysz w innych językach. 
> To jest nadal dobre rozwiązanie.
> I nie przemawia do mnie fakt, że coś gdzieś używasz raz po środku. Jeśli nie potrafisz tego znaleźć w kodzie, to znaczy że kod jest a) za długi, b) źle napisany.

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 ze
starą składnią, nikt nie narzuca siłą nowej. Wilk syty i owca niewydymana.

-- 
pozdrawiam
Roman Tyczka

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.

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

W dniu 2018-11-13 o 15:23, immo pisze:
> 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ć?

No właśnie - dlatego nie ma się co dziwić, że programiści migrują do C#.
Ale przecież nie o to chodzi?!

Pozdrawiam

On Thu, 15 Nov 2018 14:31:14 +0100, Miroo wrote:

>> 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ć?
> 
> No właśnie - dlatego nie ma się co dziwić, że programiści migrują do C#.
> Ale przecież nie o to chodzi?!

+1

-- 
pozdrawiam
Roman Tyczka

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

W dniu środa, 14 listopada 2018 17:02:05 UTC+1 użytkownik wloochacz napisał:
> Po co?

Bo tak? :) To było w sensie chcenia, a nie argumentu merytorycznego, jeśli o to Ci chodzi.

> Ile razy dziedziczyłeś z typu prostego w C#?
Ani razu. Może z tego powodu, że bardzo mnie to irytuje, w szczególności jeśli takie dziedziczenie nie robi nic dodatkowego, po za samym faktem że jest. :/
> No to ta "pełna obiektowość" nie zawsze jest potrzebna i przydatna (tak, 
> tak - wiem co napisałem).
Czy potrzebna to nie wiem, ale ja się tak jakoś przestawiłem że bardzo mnie rażą "luzem" leżące funkcje... 

> To teraz Tobie powiem - widziałeś Ty nowe Delphi?
> Bo gdybyś widział, to byś wiedział że:
> Length(s) = s.Length;
Mam subskrypcje więc robię na najnowszym dostępnym, ale przyznam się że nie wiedziałem.

> Nie rozumiem co napisałeś.

To napisałem, że jeśli coś jest w standardzie (in box) to jest domyślne dla wszystkich. Jeśli dostajesz możliwość (skądinąd bardzo dobrą i potrzebną) rozszerzania funkcjonalności, to każdy może sobie to napisać sam. Problem jest taki, że każdy może to zrobić po swojemu. I o ile nie ma problemu jeśli dostajemy cały kod, to już w komunikacji dwóch osób będą problemy, bo mówiąc o jakimś rozszerzeniu, możemy myśleć/mówić o czym innym. I tylko o to chodziło.

> Jak ktoś zaprojektuje (albo i nie) API z czapy, to potem faktycznie 
> trzeba się domyślać...
Dawniej (kilkanaście lat temu) byłem optymistą w tym zakresie. Sam albo w grupach projektowałem systemy. Były spójne i jednolite. I było super. Teraz, z czasem, muszę oglądać kod "zewnętrzny", czasami tworzony w okolicach Delphi 4 i to co widzę niestety sprowadziło mnie na ziemię i uświadomiło jak można spier... podstawowe sprawy. Pomijam częsty brak dokumentacji (albo taką dokumentację jakby jej faktycznie nie było).

> Demokracja to jest jednak najgorszy możliwy ustrój, gdzie większość "ma 
> racje" ;-)

Z jednej strony masz rację, bo słuchając "ludu" prawdopodobnie nie można byłoby przeprowadzić rewolucji. Z drugiej strony trzeba pamiętać, że to środowisko tworzone jest dla jego użytkowników, a nie dla EMB samego w sobie. Trudna sytuacja.

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

Nie można tak do tego podchodzić. Bo jeśli przyjąć by że faktycznie był projektowany w innej rzeczywistości, to oznaczałoby że nie przystaje do dzisiejszych czasów. Ergo - nie nadaje się do dzisiejszych aplikacji. A wiemy że tak nie jest. Więc albo założenia były bardziej uniwersalne niż opisujesz, albo dzieją się jakieś cuda :)

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

Przecież Pascal już umarł. Jest reanimowany, i nawet jeśli jest teraz jednym z lepszych środowisk wielo-platformowych, to zastój jakiego doświadczył kilka/naście lat temu i odsunięcie się od niego programistów jest moim zdaniem nie do odrobienia. A wielka szkoda.

Ja pewno będę w Delphi siedział nadal, po części z sentymentu, po części z uwarunkowań biznesu. Niemniej projekty robię we wszystkim co jest wymagane dla danego projektu :)

pozdrawiam,
Przemek O.

W dniu 27.11.2018 o 10:09, immo pisze:
> W dniu środa, 14 listopada 2018 17:02:05 UTC+1 użytkownik wloochacz napisał:
>> Po co?
> 
> Bo tak? :) To było w sensie chcenia, a nie argumentu merytorycznego, jeśli o to Ci chodzi.
> 
>> Ile razy dziedziczyłeś z typu prostego w C#?
> Ani razu. Może z tego powodu, że bardzo mnie to irytuje, 
Oj, Ty się dokształcić musisz :)
Powtarzam Ci, ze się nie da.

> w szczególności jeśli takie dziedziczenie nie robi nic dodatkowego, po za samym faktem że jest. :/
Szczerze?
Samo dziedziczenie, które nawet nic nie robi dodatkowego, jest jednym z 
lepszych rozwiązań w utrzymywaniu skompilowanego, obliczonego na lata 
utrzymania kodu.

Robisz klasę, która jest.
I jej używasz latami.
A potem nagle przychodzi potrzeba dodania do tej klasy czegokolwiek.
Nie masz klasy bo jest - przepisujesz wszystko.
Masz klasę co tylko jest - robisz co trzeba w jednym miejscu, reszta 
działa bez zmian.

Ja od lat np. wszystkie klasy DAL ma wydziedziczone.

>> No to ta "pełna obiektowość" nie zawsze jest potrzebna i przydatna (tak,
>> tak - wiem co napisałem).
> Czy potrzebna to nie wiem, ale ja się tak jakoś przestawiłem że bardzo mnie rażą "luzem" leżące funkcje...
> 
>> To teraz Tobie powiem - widziałeś Ty nowe Delphi?
>> Bo gdybyś widział, to byś wiedział że:
>> Length(s) = s.Length;
> Mam subskrypcje więc robię na najnowszym dostępnym, ale przyznam się że nie wiedziałem.
No widzisz, a ja nie pracuję na najnowszym, a wiem :D

A tak poważnie - zachęcam do postawienia kropki za zmienną typu prostego 
i naciśnięciu CTRL+Space - możesz się zdziwić.
Ja się zdziwiłem, ale ze względu na to, że część patentów w 
string-helper działa inaczej niż bym sobie tego życzył.

>> Nie rozumiem co napisałeś.
> 
> To napisałem, że jeśli coś jest w standardzie (in box) to jest domyślne dla wszystkich. Jeśli dostajesz możliwość (skądinąd bardzo dobrą i potrzebną) rozszerzania funkcjonalności, to każdy może sobie to napisać sam. Problem jest taki, że każdy może to zrobić po swojemu. I o ile nie ma problemu jeśli dostajemy cały kod, to już w komunikacji dwóch osób będą problemy, bo mówiąc o jakimś rozszerzeniu, możemy myśleć/mówić o czym innym. I tylko o to chodziło.
No, nie zgadzam się.
To o czym mówimy to tylko narzędzie (class helpers czy extension 
methods), które można używać różnie.
Ale one nie narzucają jakiegoś tam jedynie słusznego postępowania.
Od tego jest, że tak powiem, kultura kodowania.
Pewne wypracowane metodyki, konwencji i wzorce.

Pracujesz w dużej firmie, to powiedz; macie taką kulturę wewnątrz 
organizacji? Jakiś code guidelines na przykład?

>> Jak ktoś zaprojektuje (albo i nie) API z czapy, to potem faktycznie
>> trzeba się domyślać...
> Dawniej (kilkanaście lat temu) byłem optymistą w tym zakresie. Sam albo w grupach projektowałem systemy. Były spójne i jednolite. I było super. Teraz, z czasem, muszę oglądać kod "zewnętrzny", czasami tworzony w okolicach Delphi 4 i to co widzę niestety sprowadziło mnie na ziemię i uświadomiło jak można spier... podstawowe sprawy. Pomijam częsty brak dokumentacji (albo taką dokumentację jakby jej faktycznie nie było).
> 
>> Demokracja to jest jednak najgorszy możliwy ustrój, gdzie większość "ma
>> racje" ;-)
> 
> Z jednej strony masz rację, bo słuchając "ludu" prawdopodobnie nie można byłoby przeprowadzić rewolucji. Z drugiej strony trzeba pamiętać, że to środowisko tworzone jest dla jego użytkowników, a nie dla EMB samego w sobie. Trudna sytuacja.
Nie, wcale nie trudna, bo i dlaczego?
Sprawa jak dla mnie jest ekstremalnie prosta - to są użytkowcy jak 
każdej innej aplikacji.
I jak to użytkownicy - jedni mają genialne pomysły, a inni... no cóż.
Ja toczę podobne boje w swoim bagienku z userami - oczywiście nie ta 
skala, ale problem z definicji podobny.
Nie wiem, dla mnie to jest stosunkowo proste.
Ale ja mam pewną wizję, której się trzymam. Oczywiście ona ewoluuje, 
również przez wpływ użytkowników, ale jest spójna.

Jak to dziś mi jeden lead-user powiedział wprost: "czasem mnie Pan z 
pomysłami sprowadzi do parteru w minutę i bardzo dobrze, bo nie tracimy 
czasu na głupoty".
A więc, da się.

>>> 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
> 
> Nie można tak do tego podchodzić. Bo jeśli przyjąć by że faktycznie był projektowany w innej rzeczywistości, to oznaczałoby że nie przystaje do dzisiejszych czasów. Ergo - nie nadaje się do dzisiejszych aplikacji. A wiemy że tak nie jest. Więc albo założenia były bardziej uniwersalne niż opisujesz, albo dzieją się jakieś cuda :)
Proszę Cię...
Porównaj sobie zmiany jakie zaszły tylko w samym języku w odniesieniu do 
pierwotnych założeń.
Jest przecież tego cała masa.
A dla mnie deklaracja zmiennych inline, to tylko taki syntatic-sugar, 
podobnie zresztą jak class helper dla typów prostych.
Ale dla deva, który np. przyszedł np z C# do Delphi to zbawienie, nie 
będzie mi taki potem doopy truł, że "to taki głupie, w każdym innym 
normalnym języku jest inaczej!"
Mi się podobają zmiany, coś się w końcu tm dzieje.
Nawet przestałem jęczeć, że to zmiany dla klikaczy tylko, bo i tu jest 
zdecydowany postęp i zmiany są wszędzie.

>> To i ja Ci powiem inaczej - albo będziesz się rozwijał i dostosowywał,
>> albo czas umierać Pascalu.
> 
> Przecież Pascal już umarł. Jest reanimowany, i nawet jeśli jest teraz jednym z lepszych środowisk wielo-platformowych, to zastój jakiego doświadczył kilka/naście lat temu i odsunięcie się od niego programistów jest moim zdaniem nie do odrobienia. A wielka szkoda.
Może, ale ja bymm z tym "jednym z lepszych środowisk 
wielo-platformowych" jednak nie przesadzał.
Moim zdaniem, to jedno z lepszych narzędzi do prototypownia aplikacji 
wielo-platformowych ;-)

> Ja pewno będę w Delphi siedział nadal, po części z sentymentu, po części z uwarunkowań biznesu. Niemniej projekty robię we wszystkim co jest wymagane dla danego projektu :)

A ja nic nie powiem w tym temacie :)


-- 
wloochacz

W dniu wtorek, 27 listopada 2018 18:25:02 UTC+1 użytkownik wloochacz napisał:
> W dniu 27.11.2018 o 10:09, immo pisze:
> Robisz klasę, która jest.
> I jej używasz latami.
> A potem nagle przychodzi potrzeba dodania do tej klasy czegokolwiek.
> Nie masz klasy bo jest - przepisujesz wszystko.
> Masz klasę co tylko jest - robisz co trzeba w jednym miejscu, reszta 
> działa bez zmian.

Powiem Ci tak. Też zawsze tak myślałem. W swoich aplikacjach, których czas utrzymywania był nieokreślony, też tak mam.
Niemniej to wszystko ma sens jeśli jest zaprojektowane z głową. 
Ostatnio się przekonałem że i tak proste (a może właśnie nie) zadanie można spierniczyć... Więc nie jestem teraz do końca przekonany. W tym konkretnym przypadku o wiele szybciej dałoby się przepisać dużą część kodu niż zastanawiać się jak to rozwiązać w obliczu genialnego opakowywania typów/klas...

> No, nie zgadzam się.
> To o czym mówimy to tylko narzędzie (class helpers czy extension 
> methods), które można używać różnie.
> Ale one nie narzucają jakiegoś tam jedynie słusznego postępowania.
> Od tego jest, że tak powiem, kultura kodowania.
> Pewne wypracowane metodyki, konwencji i wzorce.

To wszystko jednak kwestia dokumentacji, pewnej powtarzalności postępowania i być może, jak to ująłeś - kultury kodowania. I teraz mamy sytuację gdy to zależy od widzimisię programisty a konwencji narzuconej przez producenta.

> Pracujesz w dużej firmie, to powiedz; macie taką kulturę wewnątrz 
> organizacji? Jakiś code guidelines na przykład?

Ostatnio w bardzo dużej. I wierz mi, nie chcesz wiedzieć...

> Jak to dziś mi jeden lead-user powiedział wprost: "czasem mnie Pan z 
> pomysłami sprowadzi do parteru w minutę i bardzo dobrze, bo nie tracimy 
> czasu na głupoty".
> A więc, da się.

Czasem tak. Takich klientów na rękach nosić. Gorzej jak się uprze, ty kodujesz, zmieniasz, a po czasie dowiadujesz się, że to jednak nie ma sensu :>

> Proszę Cię...
> Porównaj sobie zmiany jakie zaszły tylko w samym języku w odniesieniu do 
> pierwotnych założeń.

Dobra dobra - przesadzam. 

> Może, ale ja bymm z tym "jednym z lepszych środowisk 
> wielo-platformowych" jednak nie przesadzał.
> Moim zdaniem, to jedno z lepszych narzędzi do prototypownia aplikacji 
> wielo-platformowych ;-)

Skrót myślowy - dokładnie o to mi chodziło.

pozdrawiam,
Przemek O.