🚀 go-pugleaf

>
> Primo: na **** komukolwiek projekt w lazarusie? Wiesz co to znaczy
> minimalny kompilujący się przykład? Nie wiesz.

lazrusie to jest minimalny projekt , wybierasz new projekt i juz
jest .

>
>
> Bo to jest pierwsza konwersja na która natrafia i do której pasują
> argumenty. Dziwi Cię to?

tak .  bo nie powiniem dobierac pierwszej lepszej procedury  -- tylko
wlasciwa .
jezeli nie bedzie dobierac wlasciwej to caly mechanizm przeciazania
i  wlasnych operatorow  nie ma sensu .

zalozmy  ze zmienie kolejnosc wystepowania operator w unicie .
zalozmy ze komilator da wtedu w tej linijce dobry operator.
uciesze sie ze dziala --  zaczen pracowac nad programem i dopisze
gdziesz dalej
kolejny kod ktory bedzie wywolywal  ten przeciazny operator tylko
teraz
w bede chcial zeby wywolal ten drugi typ operatora -- a komilator
bedzie podstawial   "ierwsza konwersja na która natrafia i do której
pasują
 argumenty"

no i co dajej ?? --  nastapilo wzajemne zakleszczenie .

>
> Nie co popadnie tylko co mu upośledzony klepacz podłoży a co jest
> z punktu widzenia typów argumentów poprawne. Pierwsza opcja na którą
> trafi podczas lookupa i w której pasują argumenty jest wybierana.
> A jeżeli żadnej bezpośrednio nie ma, to następują 'próby z
> konwersjami'. Żadnej filozofii w tym nie ma. Pierwsze na co
> 'wpadł' to konwersja ze stringa do Abstract'a - która mu podałeś
> jako op2 - bo to później typy argumentów od razu pasują do
> istniejącego innego operatora.

to nie moze kompilator wywalic jakiegos ostrzezenia ??

wlaczylem pokazywanie  wszyskich komunikatow -- i nic . zadnego
ostrzezenia o niejawnej konwersji .

jedno oszczezenie w komunikatch i bylo by po sprawie .
mialem przeziazonych kilkanasie warianotow operatorow -- kazdy dzialal
poprawnie , az tu nagle blad i nie wiem z czego wynika w linijce
dodawania  i na sprawwdzonych operatorach , skad moglem wiedziec ze
podstawia co innego i ze tego jednego dodawanai akurat brakuje .


>
> Widzisz jakieś sensowne wytłumaczenie w jakich okolicznościach
> kompilator powinien korzystać z których dostępnych konwersji a
> kiedy z innych - też pasujących, a kiedy z kolei powinno się
> pojawiać:
>
> Error XY1235: Unit1.pas:123 - W pizdu, webmajsterek nie
>               rzeźb tak, bo mi się wydaję że to nie zadziała
>               jak chcesz. Pozdrowienia, kompilator.
>
> ? Znajduje match'a podczas lookupa, to z niego korzysta.
>
> W C++ jest od takich 'niespodzianek dla łebmajsterka' słowo kluczowe
> explicit. Doczytaj sam dla siebie.


wlasnie takiego komunikatu oczekiwalem .


>
> Kolejne Primo, powiedzmy że Secundo: nie umieściłeś w interfejsie:
>
> operator +  (A:ObjectAbstract;B:Byte):ObjectAbstract;
>
> znajduje się tylko w sekcji implementation także jeżeli
> chodzi o pierwszy z tych dwóch przykładów - sygnatura
> nie jest widoczna z innej jednostki kompilacji. I masz errora,
> bo wtedy kompilator robi upcasta do AbstractAbstract i dopasowuje
> się do sygnatury:
>
> operator +  (A:AbstractAbstract;B:Byte):AbstractAbstract;
>
> ale, obczaj, to zwraca AbstractAbstract, a nie każdy
> AbstractAbstract jest ObjectAbstractem, w obiektówce relacja is-a
> działa tylko w jedna strone.
>
> A co do 2, to nie masz operatora przyjmującego dwa concrete type'y,
> więc znowu kompilator robi dopasowanie do:
>
> operator +  (A,B:AbstractAbstract):AbstractAbstract;
>
> i znowu, nie przypiszesz wyniku do zmiennej typu ObjectAbstract.
>
> Przyjrzyj się bardzo namiętnie tym dwóm linijkom - to może
> zrozumiesz:
>
>   Test:=ObjectAbstract(Test+Byte(1));
>   Test:=ObjectAbstract(Test+Test);
>
> to nie argumenty mu tu nie pasują, tylko return-type.

wiem ze oprator + dla ObejctAbstract nie jest zadeklarowany w seksji
interface .
jest tam dla  testu  bo unit przykaldowy na ktrym wykrywalem gdzie
komilator nie dziala jak  chce jest o wiele dluzszy i  mial o wiele
wiecej testow .

>
> Z kolei te casty byłyby kompletnie niepotrzebne gdybyś tylko
> wiedział na czym polega podejście obiektowe do dziedziczenia,
> i fakt że nie jak już definiujesz kontrakt abstrakcyjny, to się
> go trzymaj... i znowu, mówiąc wprost, Twoje 2 ostatnie linijki
> działają tak jakbyś się tego spodziewał jeżeli tylko zrobisz
> zamiast:
>
> var Test:ObjectAbstract;
>
> tak:
>
> var Test:AbstractAbstract;


znowu nie jasno sie wyrazilem z tym nierownym ( niejasnym )
traktowaniem
przez komilator  w obiektach .

masz np
 var s:string;
     Test:ObjectAbstract;

  s:=Test;

i to sie wykona  mimo ze dla objektu ObjectAbstract nie
zadeklarowalem
operator := (A:ObjectAbstract ) :String;
komilator wywola metode przeodka .

logicznie myslac dla

   Test:=Test+Byte();

kompilaotr  powinien podstawic ( wedlug mnie ) podstawic opertora dla
przodka .
( wyjsc z zasady ze jezeli nie ma przeciazonego operatora dla danej
klasy szukac
wsrod przodkow  )



>
> Na dobra sprawe całokształtu Twojego potworka niebyłbym do końca
> pewien, w FPC chyba nie ma dynamicznego polimorficznego
> dispatcha operatorów - nie są member functions więc następuje
> tylko statyczna analiza na poziomie kompilacji, bo nie ma ich
> w VTABLE/VMT/DMT/jak-zwal-tak-zwał. Nie chce mi się w to wnikać.
> Projekt całości Twojego potworka posłużyłby mi raczej do
> pokazania czego się *nie robi* TBH.
>

oki -- ku chwale informatyki .

aha -- czyli  wniosek jest taki ze   nie uzywac operator do obiektow
przynajmniej do poki
nie zaimplemntowane zostana wszysztkie mechaznizmy  ( FPC 3.0 ) .