Ostatnio wywiązała się między mną a Olórinem Ciekawa dyskusja, którą jeden z nadgorliwych moderatorów wyrzucił do kosza informując mnie:

Zrozumiał bym jeszcze gdyby to nie był developer. Jednak jest on nim i to z dość ścisłego grona.
Dlatego zastanawia mnie czy obiektowość w Konnekcie będzie.
Olórin np wypowiadał się iż "wprowadzanie na siłe obiektów do kodu strukturalnego jest bez sensu". Nie do końca zrozumiałem czy to było skierowane do jego wtyczki czy do projektu konnekta. Była jeszce wypowiedź iż jemu jest łatwiej wywołać jedną z funkcji api niż odwoływać się do metody jakiegoś obiektu by uzyskać ten sam efekt.
Twórcom WinAPI też napewno było to wygodne bo znali je na wylot i nie musieli zaglądać do dokumentacji by dowiedzieć sie co i jak. Zwykły programista ma jednak problemy z przyswojeniem sobie tych wszystkich funkcji, flag, znaczników itp. DLatego Cieszą się dużym powodzeniem obiektowe nakładki na WinAPI, gdyż programistom łatwiej jest zrozumieć i posługiwać się takim systemem.

Hao pisał, że część obiektowego API już jest stworzona lub kończona (IContact, IContactGroup). No świetnie tylko "nikt" nie ma do niego wglądu nie mówiąc o jakiejś ogólnej dokumentacji. Wyjdzie nowe API i człowiek będzie musiał znowu wnikać od początku jak co wszystko działa i developerzy znowu zostana w tyle. Dlatego osobiście nie widzę większego sensu trzymania tego w tajemnicy.

Pytanie, czy tylko Hao uważa wprowadzenie obiektowości za rzecz niezbędną?

To tyle moich przemyśleń.

Chodzi mi o ten, konkretny, przypadek. Tak na prawde tabletka odwołuje się do bezpośrednio do kontaktu tylko w kilku miejscach (pobieranie nazwy, statusu i sieci do ikonek).


Zgadza się, jednak każda z takich nakładek stwarza pewne ograniczenia, przez które i tak trzeba uciekać się czystego WinAPI.


API ma być kompatybilne wstecz, więc wtyczki mają się kompilować z nowym API bez większego problemu (takie są obecne założenia). Nowe API powstaje, ale jaki sens jest jego publikowanie, kiedy nie będzie można go przetestować w użyciu? Póki co nie ma sensu wprowadzać zbędnego zamieszania. To api to nie ma być wszak nakładka na obecne - to ma być coś nowego...

Wystarczy zajrzeć na svn do branches/api_0.7 i już będziesz na bieżąco Ale jak wyżej - na wiele się ono nie przyda, jeżeli nie można go przetestować... A testować nie ma na czym, bo wydanie przejściowej wersji tylko dla devów mija się z celem i jedynie wprowadzi dużo zamieszania...

Na pewno ogromna większość API przejdzie na obiektowość... Myślę, że sama obiektowość będzie "samodokumentująca", oraz zbliżona w wielu aspektach do obecnego, więc przejście nie powinno sprawiać kłopotów...

Poza tym na pewno opiszę jakie kroki należy podjąć, żeby przenieść swój kod do nowego środowiska...

Blah, tragedia. Fantastycznie Kosiarz, że działasz aktywnie na polu deweloperskim, ale moim zdaniem czepiasz sie na siłę Bóg wie czego. Moderacja na forum zawsze była silna (choć pewnie nie będę odkrywczy jak napiszę, że można odnieść wrażenie, że kumoterska) i przytoczony cytat w moim mniemaniu tylko do tego się odnosi. Nie mam bladego pojęcia dlaczego akurat to cytujesz - IMHO nie ma to związku z resztą posta. Ale cóż...

Zastanawia Cię, czy obiektowość w Konnekcie będzie. Jest. Hao mimo iż jest hardkorowym miłośnikiem WinApi, kocha też pisanie na szablonach, co z pewnością programowaniem strukturalnym nazwać nie można (szablony w ogóle nie są częścią C). Żeby się przekonać jak pisze, wystarczy zerknąć na jego blog. Wprowadzanie obiektów na siłę jest złe, bo jest na siłę. Naprawdę, lubię obiekty, piszę na codzień w C# i mogę zrozumieć miłość do podejścia obiektowego, ale nigdy, przenigdy nie zrozumiem sensu uszczęśliwiania na siłę. To, że API wtyczek do Konnekta jest jakie jest prawdopodobnie ma jakiś głębszy sens. Osobiście stawiałbym na prostą rzecz - jakieś API musiało być dostępne od samego początku, bo Konnekt to tylko skorupka dla wtyczek. Przypuszczalnie tak było szybciej, nie wątpię też, że pisząc Konnekta Hao się uczył (nie, nie programowania obiektowego jako takiego, tylko ogólnie uczył - poszerzał swoją wiedzę) czego efektem jest być może już przestarzałe API. Gdyby Hao kazał czekać na dopieszczonego K z doskonałym API to pewnie nie byłoby tego komunikatora jeszcze przez kilka lat.

Konnekt ewoluuje a osób zdolnych _naprawdę_ przyczynić się do rozwoju rdzenia jest niewiele. Zresztą Hao nie dopuszcza do kodu K każdego kto chciałby, bo i po co? Słomiany zapał cechuje 95% populacji Internetu. Przekłada się to na prostą rzecz - wszystko się toczy baaardzo wolno. Z braku mocy przerobowych API jest kiepsko udokumentowane i podobnie jak K ewoluuje niespiesznie. No i co z tego? Nikt nigdy nikomu nie obiecywał doskonałej aplikacji, więc postawa roszczeniowa jest conajmniej śmieszna. Jest jak jest i trzeba z tym żyć. Zresztą, wracając do zdania "wprowadzanie na siłę obiektów do kodu strukturalnego jest bez sensu" - jest ono w 100% prawdziwe. Zwróć proszę uwagę, że nie ma większej różnicy czy kod jest oparty o procki i stado definicji czy o zastępy klas i enumeracji - bez dokumentacji do API czyta się to tak samo (pod warunkiem, że i jeden i drugi kod rozumie się tak samo dobrze ). Jakoś przykład z WinApi absolutnie do mnie nie trafia.

Czemu nikt nie ma wglądu z zmiany API, które nie są publiczne? Bo nie są publiczne (pominę tak drobny szczegół jak to, że stawiam stówę, że niektórzy mają ). Zresztą pominę żurem koherentnym jak byłbyś niezadowolony, gdyby nowe API (jeszcze niedostępne) było już opisane i zmieniłoby się wraz z finalną, publiczną wersją. Cały czas przecież się o to rozchodzi - zmienia się "jawnie" to źle, "w tle" też niedobrze. Polska...

Co do wątku, z którego jak sądzę wziął się ten temat - napisałem w dyskusji o tabletce, że obiektowe API w niczym tej wtyczce nie pomoże, bo większość magii czyniona jest w WinApi. Konnekt jakiego by API wtyczek nie miał - wraperem na WinAPI nie będzie, bo i po co? Zresztą napisał też o tym powyżej Olórin.

Podsumowując: przemyślenia przemyśleniami, ale nie jest to żadna konstruktywna krytyka tylko wypunktowanie faktów i wskazanie, że Ci się to nie podoba. Propozycji nowelizacji brak.

KosiarzPL: cos co jest dobre nie wymaga "propagandy". deweloperzy nie sa pozbawieni oczu ani myszki i zdaja sobie sprawe z istnienia Twojej "cudownej" klasy, a to, ze nikt nie pali sie do jej uzywania jest juz wynikiem jej jakosci, nie przeoczenia.

PS. zacznij kontrolowac klawiature, bo bledy (literowki + ortografy) robisz nagminnie, co tylko poglebia negatywne wrazenie...

To było wtrącenie na temat moderacji panującej na forum i głupim komentarzom takową moderację usprawiedliwiającą (co mnie osobiscie zdenerwowało). W dodatku był to przykład ignorancji wobec poważnej dyskusji o obiektowości przez tego developera. Co mnie włąśnie tknęło do przemyśleń.


Może częścią C nie są ale jak najbardziej C++.



Blog czytam no ale tam nie wiele można się dowiedzieć na temat postępów w K. Owszem od czasu do czasu są pewne informacje o postępach. Nie rozumiem co znaczy "wprowadzanie obiektów na siłe". Nikt nie każe ich prowadzać na siłę. Uważam tylko iż programowanie obiektowe jest o wiele wydajniejsze niż strukturalne. W tej dyskusji chcę tylko wybadać jakie są tendencje wśród developerów. Czy wolą zostać przy obecnym API czy jednak wspierają w jakiś sposób Hao w jego zmianie. Uważam również iż stworzenie obiektowego API jest o kilka klas trudniejsze niż dostarczenie API strukturalnego. Gdyż tu juz nie chodzi o opakowanie obecnych funkcji w klasy ale o stworzenie całego modelu od początku. Jednak wysiłek zwróci się napewno bardzo szybko poprzez zmniejszenie czasu na napisanie wtyczki oraz poprawienie ich poprawności.

Ja doskonale rozumiem w jakich warunkach powstawało obecne API i niejest to temat na tą dyskusję. Uważam, że stare API należy zostawić w spokoju nawet za cenę pewnej niekompaktybilności (co chyba się dzieje sądząc po niektórych postach hao).


A no właśnie dużo. W końcu powstanie znowu niepełna dokumentacja. Sam doskonale wiem ile zabiera czasu budowa takiej dokumentacji. Ale czy nie dało by się znaleźć kilku osób które by na bierząco dokumentowały zakonczone partie kodu? Choćby robiły tylko szablon dla dokumentacji takiej klasy. Ja widze, że Hao jest zwolennikiem extreme programming, ja osobiście taki nie jestem


Akurat z tą wypowiedzią to ja się w 100% nie zgadzam. Nikt tu nie ma postawy roszczeniowej. Moja postawa to propozycja zmian.
Między kodem strukturalnym a obiektowym jest kolosalna różnica. Powiedz mi ile ci zajęło przyswojenie sobie programowania w WinAPI a ile w .NET Forms? A ile by ci zajęło to samo dodatkowo bez dokumentacji do pierwszego i do drugiego. Bo czym jest .NET? Obudówką obiektową do WinAPI. Ze swojej storny mogę Ci powiedzieć, że zrozumienia mechanizmów jakie działaja w .NET zajęło mi 2 dni. Zacząłem pisać większe aplikacje po tygodniu i nie musiałem zaglądać non stop do MSDNa. A jak się sprawa ma z WinAPI? Tam jedna funkcja może służyć do 1000 zstosowań w zależności jaką mu flagę podasz i bez MSDNa nie ma co podchodzić do pisania aplikacji. Chyba, że masz mega mózg i zapamietasz że wstawiając flagę X oraz flagę Y w tym miejscu i wywołując funkcję otrzymasz w pierwszej częsci zmiennej A indeks w drugiej cześci zmiennej A uchwyt, w zmiennej... No i oczywiście musisz pamiętać wszystkie kombinacje i nazwy flag bo przecież one nie są powiązane ściśle z żadną funkcją.
Sam mówisz , że programujesz w C#. Ciekawe czemu nie robisz tego w WinAPI, przecież to to samo. Tu i tu masz uchwyty do okien, dostęp do WinAPI. Ile zajmuje stworzenie edytora tekstu MDI w obu przypadkach?


Ja bym narzkał, że dokumentacja API się zmienia? Chyba żartujesz. Było by o czym dyskutować, można by było proponować, pytać.


Ależ ja nie mam nic do zarzucenia tabletce. Mnie mało interesuje to jak ona działa, czy jest napisana obiektowo czy nie. W końcu to nie ja zarządzam tym projektem, to nie ja będę musiał go przerabiać, utrzymywać, pamiętać co i gdzie.
No i oczywiście nikt nie każe K być wraperem do winAPI, nie wiem do kogo to kierujesz. Choć oczywiście powinien w niektórych przypadkach takim wraperem być i jest.



No jeśli wskazuję co mi sie ine podoba to jednak jakaś to krytyka (według mnie konstruktywna) jest.
Propozycje? Proszę:
- otworzyć stronę wiki dla wszystkich zainteresowanych poprzez umożliwienie im komentowanie a nie tylko czytanie
- powolać kilka osob do dokumentowania nowego api
- jakiś opis postępów, wystarczy krótka informacja jak w jednym z tematów gdzie zostało podane jakie klasy są juz gotowe a nad jakimi sie pracuje, to by mi wystarczylo. Ja che miec tylko ogolny wyglad modelu api
- udostepnic gotowe moduly jak do obslugi dtb by ludzie mogli potestowac i sie przywyczaic a dzieki temu i wy dostaniecie dodatkowych testerów


Ja nie zmuszam nikogo do używania mojej biblioteki. Nie nazywam jej cudowną i nie posiada ona jednej klasy. Jestem ciekaw czy chociaz raz spróbowałeś jej użyć. Ja do jej działąnia nie mam żadnych zastrzeżeń i bardzo mi ułatwia pisanie wtyczek. I taki cel ma ta biblioteka, ułatwiać. Więc jeśli jej ani razu nie podlinkowałeś i nie użyłeś nie powinieneś się w ogóle wypowiadać jej jakości. A jeśli masz konkretne zastrzeżenia ja chętnie je wysłucham, jak wysłuchałem Olórina.


Ja w przeciwieństwie do innych osądzam ludzi po tym jak piszą a nie co piszą. Wszystkie literówki i błędy staram się poprawiać a to że dobrym pisarzem nie jestem wiem sam.

Odpowiem skrótowo, bo czas iść się drzemnąć.

Moderacja jaka jest taka jest. Zamiast się denerwować zesłaniem notki dośmietnika przeważnie warto się zastanowić nad wartością merytoryczną spłukanej notki i faktyczną powagą dyskusji. Moim zdaniem nie była ona poważna, jako przykład niech stanowi fakt, że na uwagę Olórina, że woli użyć procki (+linijka kodu) odpisałeś, że przecież można fajniej (+kilka linijek kodu obiektowego). Poważne to to nie jest.

Wiem czego częścią są/nie są szablony. Chciałem Ci nakreślić, że fakt ich wykorzystania przy pisaniu K świadczy o "obiektowości" kodu, co z kolei było odpowiedzią na Twoje pytanie: czy K będzie obiektowy. Jest - napisałem o tym jasno, kilkukrotnie na różne sposoby (jak mi się, chyba błędnie, wydawało miało to wpłynąć pozytywnie na zrozumienie tekstu przez przedpiścę).

"Uważam tylko iż programowanie obiektowe jest o wiele wydajniejsze niż strukturalne." - a ja uważam, że Elvis żyje. Przekonujące? A skądże... Pisanie kodu to nie wybór demokratyczny - każdy pisze jak chce i w czym chce, nie rozumiem zatem sensu takiej ankiety. Chciałeś żeby ktoś Cię przekonał do pisania strukturalnego?

"Uważam również iż stworzenie obiektowego API jest o kilka klas trudniejsze niż dostarczenie API strukturalnego." - właśnie widać tą wydajność, o której pisałeś dwa zdania wcześniej. Im coś jest trudniejsze tym prawdopodobnie mniej wydajne w rękach tego, dla którego jest to trudne (mówię tutaj o metodologii a nie algorytmice).

"wysiłek zwróci się napewno bardzo szybko poprzez zmniejszenie czasu na napisanie wtyczki oraz poprawienie ich poprawności" - dajesz na to gwarancję? Na ile miesięcy? Jak zachęcisz piszących wtyczki do obiektowego API? Bo do tej pory czytam tylko slogany a nie solidne argumenty. Jeśli chcesz kogoś do czegoś przekonać (co z kolei przeczy rzekomej chęci poznania zdania deweloperów) to potrzebujesz argumentów.

"Uważam, że stare API należy zostawić w spokoju nawet za cenę pewnej niekompaktybilności (co chyba się dzieje sądząc po niektórych postach hao)." - bardzo radosne podejście dewelopera do spraw konsumenckich.

"Ale czy nie dało by się znaleźć kilku osób które by na bierząco dokumentowały zakonczone partie kodu?" - pewnie dałoby się, tylko ponownie spytam czym się różni dobrze udokumentowany kod obiektowy od takiegoż strukturalnego?

" Ja widze, że Hao jest zwolennikiem extreme programming, ja osobiście taki nie jestem" - ja tego nie widzę, bo nigdy nie słyszałem o testach jednostkowych kodu Konnekta, co jest jedną z podstaw programowania ekstremalnego. Chyba użyłeś złego terminu.

"Nikt tu nie ma postawy roszczeniowej." i "Uważam, że stare API należy zostawić" oraz "był to przykład ignorancji wobec poważnej dyskusji". To nie jest postawa roszczeniowa?

"Powiedz mi ile ci zajęło przyswojenie sobie programowania w WinAPI a ile w .NET Forms?" - zakładam, że piszesz o Windows Forms. Używa się ich tak samo w momencie, kiedy potrzebujesz czegoś więcej niż dostarczone OOTB kontrolki. Tak samo było jest i będzie z wraperami WinApi (vide Delphi). A opanowywałem WinApi dłużej, bo było pierwsze. Co więcej - jestem zdania, że zaczynanie od wysokopoziomowych rzeczy pokroju Windows Forms ogranicza możliwości poznawcze dewelopera.

"zrozumienia mechanizmów jakie działaja w .NET zajęło mi 2 dni" - w takim razie wybacz, ale G**** rozumiesz. To, że napisałem dużą aplikację po tygodniu z Borland Pascalem (mój pierwszy język, sam sex ) zupełnie nic nie znaczy i nie świadczy, że cokolwiek opanowałem, rozumiałem lub potrafiłem zrobić. Z perspektywy czasu (jakieś 9 lat) mogę natomiast powiedzieć, że mój kod był śmieszny, zdolności marne, muppet-proof aplikacji miałki. A najśmieszniejsze jest to jaki napuszony i dumny byłem z mojej bazy danych uczniów.

Czepiasz się flag - udowodnij, że są lepsze od enumów i pól klasy. I że uchwyty są czymś innym niż wskaźniki do klas. Słucham.

"Sam mówisz , że programujesz w C#. Ciekawe czemu nie robisz tego w WinAPI, przecież to to samo." - nie przyszło Ci do głowy, że a] piszę aplikacje ASP.NET b] pracodawca wymaga takiego a nie innego języka?

"Ja bym narzkał, że dokumentacja API się zmienia? Chyba żartujesz." - a co Ty u licha robisz? Że aż zacytuję: "Wyjdzie nowe API i człowiek będzie musiał znowu wnikać od początku jak co wszystko działa i developerzy znowu zostana w tyle."

"otworzyć stronę wiki" - piszesz na forum pewnej społeczności. Zawsze było tak, że to społeczności wychodziły z ciekawymi inicjatywami i często same je realizowały. Postaw wiki. Aha, i zapewnij wysoką jakość tekstu (tzn. znajdź chętnych do weryfikowania tego, cu ludzie wypisują). Samoutrzymująca się wiki to mit.
"powolać kilka osob do dokumentowania nowego api" - hasło w stylu "wyrabiajcie 300% normy". Ja popatrzę.
"jakiś opis postępów" - zgoda. Z jednej strony Hao poleca pytać na forum, bo "skorzystają wszyscy", z drugiej trudno się oprzeć wrażeniu, że support wcale nie niechętnie świadczony jest poza forum.
"udostepnic gotowe moduly jak do obslugi dtb" - a dlaczego akurat to a nie udostępnić X, Y albo Z? Możliwość potestowania to żadne uzasadnienie.

"Ja w przeciwieństwie do innych osądzam ludzi po tym jak piszą a nie co piszą. " - chyba miało być odwrotnie. =]

Miało być krótko, wyszło jak zawsze...

Czy ktoś zauważył mojego posta?

Nowe API JEST dostępne! Dokumentacja tworzona jest doxygenem, więc jak ktoś chce - może je dokumentować

svn://svn.konnekt.info/konnekt/branches/api_0.7

Stamina.lib potrzebna do jej lepszego "poznania" jest tutaj - dostęp na razie za requestem

svn://svn.konnekt.info/staminalib/trunk

Wiki tak na prawdę też jest ogólno dostępne, nie publikujemy jego adresu, żeby na razie zepełniło się treścią, a nie pytaniami O ile pamiętam konto może na nim założyć każdy, podobnie tworzyć nowe wątki...

Ryan, muszę jednak przyznać rację Kosiarzowi - z "prawidłowego" kodu obiektowego można wyczytać znacznie więcej, chociażby przeglądając metody klasy... Taki kod znacznie łatwiej poddaje się kontroli, szybciej można wychwycić błędy.

WinApi jest miejscami małym koszmarkiem, a Stamina.Lib jest w dużej mierze wrapperem na niego

Zauważył, ale nadal nie rozumiem o co się Kosiarzowi rozchodzi - raz pisze, że przeszkadza mu strukturalny charakter API, raz, że się zmienia, później znowu, że się nie zmienia...

"Wiki (...) jest ogólno dostępne, nie publikujemy jego adresu" - a to się ubawiłem. =]

Nadal nie zgodzę się z tą czytelnością, bo wygląda na to, że porównujemy niechlujny kod strukturalny do (przynajmniej) znośnego obiektowego. Metodami w klasie można się tak samo kierować jak np. prefiksami zmiennych, definicji czy - w najprostszym przypadku - nazwą pliku z którego pochodzą. Nawet sąsiedztwo definicji i funkcji wiele mówi o ich przynależności. Jasne, jak ktoś rozrzuca kod bez ładu i składu po plikach, albo tworzy potworny_kod_strukturalny.c z kilkudziesięcioma tyciącami linii, to tego się nie da czytać. Ale to samo można zarzucić analogicznemu bałaganowi w kodzie obiektowym.

Programowanie ekstremalne -> kod dokumentowany przez testy jednostkowe i komentarz w kodzie, pisanie w parach.

Więc rzeczywiście, hao nie pisze ekstremalnie, ale z nieco innych powodów niż podałeś (chyba, że czegoś nie wiemy - hao, jest Ciebie dwóch? ;-) ).

Są i testy jednostkowe, i dokumentacja w kodzie (zazwyczaj ;-)), więc mamy czystej wody agile programing, którego jedną z odmian jest XP. Howgh!

Kodowanie w XP rozpoczyna się od pisania testów, by zapewnić implementację tylko potrzebnych funkcjonalności. Napisałem przecież, że to jest "jedną z podstaw programowania ekstremalnego" a nie wyłącznym kryterium.

// Cytat wyciąłem - prosimy nie cytować całego ostatniego posta w temacie.

[quote]
Moderacja jaka jest taka jest. Zamiast sie denerwowac zeslaniem notki dosmietnika przewaznie warto sie zastanowic nad wartoscia merytoryczna splukanej notki i faktyczna powaga dyskusji. Moim zdaniem nie byla ona powazna, jako przyklad niech stanowi fakt, ze na uwage Olórina, ze woli uzyc procki (+linijka kodu) odpisales, ze przeciez mozna fajniej (+kilka linijek kodu obiektowego). Powazne to to nie jest.
[/quote]
Nie zdenerwował mnie fakt zesłania notki do śmietnika ile razy mam mówić. Notka została wysłąna do śmietnika z powodu "propagandy" i to mnie tylko zdenerowało. Dyskusja jak najbardziej zaczynała być poważna tylko nie na temat wtyczki co Olórinowi jak najbardziej mogło sie nie podobać a temat można było wydzielić do innego wątku. A dlaczego poważna? Powtórze jeszcze raz bo chciałem poruszyć temat obiektowości w K. I nie mówiłem, że moje rozwiązanie jest fajne. Czego ty się czepiasz. Zaproponowałem tylko rozwiązanie i JEDNA (nie kilka) linijek dłuższe (jeśli chcsz się czepiać linijek). Zostawmy jednak ten temat jest chyba o czym dyskutować.

[quote]
Wiem czego czescia sa/nie sa szablony. Chcialem Ci nakreslic, ze fakt ich wykorzystania przy pisaniu K swiadczy o "obiektowosci" kodu, co z kolei bylo odpowiedzia na Twoje pytanie: czy K bedzie obiektowy. Jest - napisalem o tym jasno, kilkukrotnie na rózne sposoby (jak mi sie, chyba blednie, wydawalo mialo to wplynac pozytywnie na zrozumienie tekstu przez przedpisce).
[/quote]
Może wiesz, może nie wiesz. Nie rozumiałem tylko po co wtrąciłeś informację o C. WIęc CIe uświadomiłem tylko.

[quote]
"Uwazam tylko iz programowanie obiektowe jest o wiele wydajniejsze niz strukturalne." - a ja uwazam, ze Elvis zyje. Przekonujace? A skadze... Pisanie kodu to nie wybór demokratyczny - kazdy pisze jak chce i w czym chce, nie rozumiem zatem sensu takiej ankiety. Chciales zeby ktos Cie przekonal do pisania strukturalnego?
[/quote]
No jasne, że mnei nie przekonałęś nie podając żadnych przykładów. Oczywiście chciałbym by mnie ktoś (np ty, taki wielki zwolennik i nie pisz, że takim nie jesteś) przekonał mnie do pisania kodu strukturalnego jeśli uważa, że jest to lepsze rozwiązanie. Ja nie stoję twardo na swoim stanowisku tylko slucham doświadczeń innych.
Ja podałem Ci ogólne zalety obiektowości w kilku ogólnych przykłądach. Widze,że to bie trzeba pokazać palcem, choć i tak nie przyznasz mi racji. Bo jak dotąd atakujesz komentując fragmenty moich wypowiedzi zamiast przedstawić jasno twój punkt widzenia. Czyli co jest złego w tym, że ja "domagam się" obiektowości w K. Bo takie jest twoje stanowisko.

[quote]
"Uwazam równiez iz stworzenie obiektowego API jest o kilka klas trudniejsze niz dostarczenie API strukturalnego." - wlasnie widac ta wydajnosc, o której pisales dwa zdania wczesniej. Im cos jest trudniejsze tym prawdopodobnie mniej wydajne w rekach tego, dla którego jest to trudne (mówie tutaj o metodologii a nie algorytmice).
[/quote]
Ze co? Porównujesz dwie ODRĘBNE kwestie. Gdy mówiłem o wydajności programowania obiektowego, mówiłem o programistach korzystających z API obiektowego. Wtedy właśnie programowanie obiektowe pokazuje swoje zalety.
Gdy mówię o trudności w tworzeniu obiektowego API to mówię o zespole przygotowującym to API. W końcu jeśli tworzy się API to nie robi się tego dla siebie. Tak? A używanie API obiektowego jest o niebo wygodniejsze od strukturalnego.
Więc ja nie wiem co ma na celu porównanie trudnści stworzenia takiego API z łatwością (wedłóg ciebie, trudnościa) korzystania z niego.

[quote]
"wysilek zwróci sie napewno bardzo szybko poprzez zmniejszenie czasu na napisanie wtyczki oraz poprawienie ich poprawnosci" - dajesz na to gwarancje? Na ile miesiecy? Jak zachecisz piszacych wtyczki do obiektowego API? Bo do tej pory czytam tylko slogany a nie solidne argumenty. Jesli chcesz kogos do czegos przekonac (co z kolei przeczy rzekomej checi poznania zdania deweloperów) to potrzebujesz argumentów.
[/quote]
Gwarancja? Moge zagwarantować, że jeśli ukaże się dobre API obiektowe to programiści sami na nie się przesiądą i gwarantuję, że będą pisać wtyczki szybciej.
Jak twoim zdaniem mam wybadać "chęci" developerów jak nie poprzez dyskusję? Ja proponuję rozwiązaine a oni się wypowiadają na ten temat. Więc gdzie tu jest sprzeczność.
Argumentów to na razie brakuje Tobie. Jak do tej pory nie podważyłeś w ani jednym zdaniu mojej tezie "słuszności obiektowego API".

[quote]
"Uwazam, ze stare API nalezy zostawic w spokoju nawet za cene pewnej niekompaktybilnosci (co chyba sie dzieje sadzac po niektórych postach hao)." - bardzo radosne podejscie dewelopera do spraw konsumenckich.
Ja nie wiem gdzie ty pracujesz.
[/quote]
1. Sam mówiłeś, że najpewniej Hao uczył się tworząc API. Skoro tak było to API chcąc nie chcąc zawiera błędy. Jeśli chcemy stworzyć nowe, lepsze API napewno nie obędzie się bez pewnych ograniczen w zgodności wstecz.
2. Wszystkie nowe rozwiązania w pewnym momencie też zrywają ze zgodnością. Miało by sens trzymać przestarzałych technik tyko dlatego by nieliczne "urządzenia" mogły działąć? Nie raz się spotkałeś z worningiem "deprected" "obsolte" podczas programowania więc możesz być pewien, że ten kawałek kodu w przyszłości nie będzie działął. Więc jest to praktyka stosowana przez większe projekty, więc tym bardziej moż być zastosowana tutaj.
Oczywiście nie namawiam do całkowitego odrzucenia starego API. Przykłądem zamierzonej niezgodności jest chociażby wycofanie funkcji "IMessageDirect".
Za to ty byś mi przedstawił swoje argumenty przeciw a nie jak zykle pusta krytyka.

[quote]
"Ale czy nie dalo by sie znalezc kilku osób które by na bierzaco dokumentowaly zakonczone partie kodu?" - pewnie daloby sie, tylko ponownie spytam czym sie rózni dobrze udokumentowany kod obiektowy od takiegoz strukturalnego?
[/quote]
A co to ma do rzeczy? Ja mówię o równoległym powstawianiu dokumentacji wraz z projektem. Czego ty się znowu czepiasz?
Jeśli już jednak się pytasz to odpowiadam (choć przykład już dałem w poprzedniej wypowiedzi). Jeśli mam dobrze stworzone API NIE muszę biegać non stop do dokumentacji i srawdzać jakiej flagi użyć by pobrać jakąs wartość wystarczy, że raz sprawdziłem na podobnej klasię jak to się robi czyli np poprzez wywolanie "Get_potrzebna_wartosc" i już wiem że tak będzie w pozostałych obiektach. Nawet jeśli nie jest to identyczna metoda samo wyświetlenie dostępnych metod obiektu w IDE i wpisujać Get_ mnie naprowadzi. Jak by to wyglądało w strukturalnym? Patrzę jak pobrać wartość tekstową dla elementu X acha używam flagi A. Teraz chce pobrać tą wartość dla zupełnie innego elementu choć z tej samej rodziny to muszę użyć innej Y? I to jest ta różnica! W programowaniu obiektowym posługujesz się dunkcjonalnością obiektu a nie zestawem funkcjonalności programu dzieki której możesz kontorlować elementy obiektu. Jeśli tego nie rozumiesz to nie mamy chyba o czym dyskutować.

[quote]
" Ja widze, ze Hao jest zwolennikiem extreme programming, ja osobiscie taki nie jestem" - ja tego nie widze, bo nigdy nie slyszalem o testach jednostkowych kodu Konnekta, co jest jedna z podstaw programowania ekstremalnego. Chyba uzyles zlego terminu.
[/quote]
Nie użyłem złego określenia.
1. O testowaniu jednostkowym mówił choćby na swoim blogu, nakłąniając do używania CPPUNIT
2. Uważa że dokumentają projektu powinien być sam kod
3. Nie ma procesu wytwórczego projektu.

[quote]
"Nikt tu nie ma postawy roszczeniowej." i "Uwazam, ze stare API nalezy zostawic" oraz "byl to przyklad ignorancji wobec powaznej dyskusji". To nie jest postawa roszczeniowa?
[/quote]
Roszczeniowa wobec czego? Czowieku konkrety a nie wycinasz móje wypowiedzi i stawiasz glupie pytanie. Mam powycinac twoje i ci udowadniac cos na sile?
Pierwsza wypowiedź, potwierdza że nie mam postawy roszczeniowej
Druga wypowiedź, jest to tylko moja uwaga, propozycja? Każda propozycja to twoim zdaniem roszczenie? Czy ja nalegam, błagam, żądam?
Trzecia wypowiedź, nie wiem dlaczegoą ją zacytowałeś.

[quote]
"Powiedz mi ile ci zajelo przyswojenie sobie programowania w WinAPI a ile w .NET Forms?" - zakladam, ze piszesz o Windows Forms. Uzywa sie ich tak samo w momencie, kiedy potrzebujesz czegos wiecej niz dostarczone OOTB kontrolki. Tak samo bylo jest i bedzie z wraperami WinApi (vide Delphi). A opanowywalem WinApi dluzej, bo bylo pierwsze. Co wiecej - jestem zdania, ze zaczynanie od wysokopoziomowych rzeczy pokroju Windows Forms ogranicza mozliwosci poznawcze dewelopera.
[/quote]
WinAPI używa się zupełnie inaczej niz Formsów. Potrzebujesz menu? Tworzysz obiekt menu i dodajesz go wywolujac metode "okna". Potrzebujesz przycisku, checkboxa, editboxa tworzysz obiekt dodajesz do okna. Potrzebujesz pobrać jakaś wartość z danej kontrolki wywolujesz metode kontrolki. Co najważniejsze potrzebujesz obslużyć jakieś zdażenie dodajesz swoja funkcję doobsługi zdażenia a nie ładujesz wszytko w jedną wielką funkcję sprawdzasz kilka flag po drodze (które musisz najpierw sprawdzić w dokumentacji) i wyłuskujesz odpowiednie wartości z kilku zmiennych. Nie muszisz pamiętać flag, jakiej metody użyć by pobrać wartość wywołujesz tylko metodę obiektu. Ale o tym już pisałęm. Poza tym nie dyskutujemy tu o różnicach winAPI nad Formsami, podałem to jako przykład wyższości API obiektowego nad strukturalny.
I jestem zdania, że dostarczenie programiscie api wysokopoziomowego ulatwia mu poznanie platformy na jakiej będzie pracować. W żaden sposób go ine ogranicza.

[quote]
"zrozumienia mechanizmów jakie dzialaja w .NET zajelo mi 2 dni" - w takim razie wybacz, ale G**** rozumiesz. To, ze napisalem duza aplikacje po tygodniu z Borland Pascalem (mój pierwszy jezyk, sam sex ) zupelnie nic nie znaczy i nie swiadczy, ze cokolwiek opanowalem, rozumialem lub potrafilem zrobic. Z perspektywy czasu (jakies 9 lat) moge natomiast powiedziec, ze mój kod byl smieszny, zdolnosci marne, muppet-proof aplikacji mialki. A najsmieszniejsze jest to jaki napuszony i dumny bylem z mojej bazy danych uczniów.
[/quote]
A co ty możesz wiedzieć ile ja rozumiem? Na twoim miejscu powstrzymał bym się z takimi wypowiedziami. Co ty jasnowidz jestes? Nakreśliłem tylko różnicę czsu jaka jest potrzebna do napisania takiej samej aplikacji w Formsach i WinAPI. Mało mnie interesuje to jakiej jakości kod ty posałeś jak byłeś dzieckiem i jak go teraz oceniasz. Chyba nie łąpiesz tematu jaki tu poruszamy.

[quote]
Czepiasz sie flag - udowodnij, ze sa lepsze od enumów i pól klasy. I ze uchwyty sa czyms innym niz wskazniki do klas. Slucham.
[/quote]
O człowieku, porażka. Po pierwsze czemu to ja mam udowadniać, a ty co będziesz robił wycinał moje wypowiedzi i komentował nie wnosząc nic do tematu.
Czasami mam wątpliwości czy ty programujesz zarobkowo, bo kto powiedział że obiektowe programowanie polega na zamianie flag na enumeracje!? Litości. Gdy tworzysz API obiektowe posługujesz się obiektami i ich odpowiedzialnościami. Odpowiedzialność klasy przekładana jest na jej metody. I nimi sie posługujesz a nie flagami/enumeracjami. Enumeracje mogą służyć do porównania jakichś standardowych wyników swracanych przez funkcję a nie do sterowania zachowaniem funkcji.
Przykład
Pobranie imienia kontatu:
strukturalne api K:

uzycie obiektowego kAPI:


Gdzie programista używa w przypadku kAPI flagi? Podpowiem, nigdzie! A ilu używa w standardowym K? Dwuch do tego potrzebuje jeszce przetrzymywać id.

Co do wskazników uchwyt np do okien jest zupelnie czym innym niz wskaznik do klasy? Nie wiesz o tym? Czym się rózni? Tym ze uchwyt do okna nie potrafi nic zrobic, to jest tylko zimenna. Uchwyt do klasy zawiera funkcjonalność potrafi zrobic to do czego dana klasa jest stworzona. Uchwyt nic nie jest w stanie zesoba zrobic. Inna sprawa, że w programowaniu wysokiego poziomu NIE ma wskazników i to jest w tym piękne. Wskażniki to przeszłość.

[quote]
"Sam mówisz , ze programujesz w C#. Ciekawe czemu nie robisz tego w WinAPI, przeciez to to samo." - nie przyszlo Ci do glowy, ze a] pisze aplikacje ASP.NET b] pracodawca wymaga takiego a nie innego jezyka?
[/quote]
Nie zastanawiałem sie nad tym. To pytanie raczej mialo wydzwięk. W czym ci się łatwiej pisze Formsach czy WinAPI. Dlaczego Twoj pracodawca wymaga Formsów bo są trudniejsze i wolniej sie w nim pisze? Nie odpowiedziałeś mi na pytanie ile zajęło by ci czasu napisanie edytora tekstu MDI w oby technologiach? Nie czepiaj się nic nie znaczących scegółów

[quote]
"Ja bym narzkal, ze dokumentacja API sie zmienia? Chyba zartujesz." - a co Ty u licha robisz? Ze az zacytuje: "Wyjdzie nowe API i czlowiek bedzie musial znowu wnikac od poczatku jak co wszystko dziala i developerzy znowu zostana w tyle."
[/quote]
Znowu sklejasz moje wypowiedzie.
Pierwsza wypowiedz tyczyla sie twojej wypowiedzi, gdzie uważasz iż będziemy narzekać na zmiany w dokumentacji gdy ta będzie powstawać wraz z nowym API. Co niesie za sobą też zmiany dokumentacji. Na to bym nie narzekał w końcu jest oczywiste, że w trakcie tworzenia może się coś zmienic
Druga wypowiedz dotyczyła sytuacji gdy wyjdzie nowe api bez dokumentacji. Dokumentacja powstanie dopiero po jakimś czasie lub nawet jesli powstanie dość szybko nię będzie kompletna. I tu bym narzekał że trzeba wnikać od nowa bo nie miałem kiedy przeciez poczytać o nowym API bo przeciez dokumentacji nigdzie nie bylo nawet szczątkowej.
Czytać ze zrozumieniem proszę i nie sklejac moich wypowiedzi dotyczących dwóch róznych kwesti.

[quote]
"otworzyc strone wiki" - piszesz na forum pewnej spolecznosci. Zawsze bylo tak, ze to spolecznosci wychodzily z ciekawymi inicjatywami i czesto same je realizowaly. Postaw wiki. Aha, i zapewnij wysoka jakosc tekstu (tzn. znajdz chetnych do weryfikowania tego, cu ludzie wypisuja). Samoutrzymujaca sie wiki to mit.
"powolac kilka osob do dokumentowania nowego api" - haslo w stylu "wyrabiajcie 300% normy". Ja popatrze.
"jakis opis postepów" - zgoda. Z jednej strony Hao poleca pytac na forum, bo "skorzystaja wszyscy", z drugiej trudno sie oprzec wrazeniu, ze support wcale nie niechetnie swiadczony jest poza forum.
"udostepnic gotowe moduly jak do obslugi dtb" - a dlaczego akurat to a nie udostepnic X, Y albo Z? Mozliwosc potestowania to zadne uzasadnienie.
[/quote]
Pozniej na to odpoiwem

[quote]
"Ja w przeciwienstwie do innych osadzam ludzi po tym jak pisza a nie co pisza. " - chyba mialo byc odwrotnie. =]
[/quote]
Tak mój bład. Z pośpiechu :/

A teraz przykład jak obiecałem.

Kod W kAPI


Ten sam kod w obecnym K


Ile trzeba bylo uzyc flag w obu przypadkach? Ile odnalezc funkcji ktore by robily to co chcemy?

A teraz zrobmy to samo tylko dla pewnej grupy
kAPI


w K nawet mi sie nie chce mi sie szukac i tego pisac.

PS. Ktoś wie czemu mi cytaty nie działąją?

DTgetID jest zbędne, DTgetStr sam sobie ją wywołuje

Unittesty w K dopiero będą i to też pewnie mocno okrojone... Właśnie piszę klasy do łatwego integrowania CPPUNIT z K.

Przyznam, że po tylu latach programowania i skakania po językach i stylach, nie znalazłem nic lepszego niż OO. Doskonałym przykładem jest do bólu strukturalne LibGadu i bardzo obiektowe JabberOO... Chociaż LG jest dobrze udokumentowane, oraz rozsądnie ponazywane / podzielone na części, to JabberOO z poważnymi lukami w dokumentacji udało mi się zaprzęc do działania znacznie znacznie szybciej... Oraz co bardzo ważne, modyfikowanie JabberOO, właśnie dzięki jego obiektowości nie nastręcza problemów, podczas gdy modyfikowanie libgadu potrafi nieźle dać w kość...
Teraz wolę przeznaczyć kilka % więcej pamięci i poświęcić kilkaset taktów procesora na przesadzoną obiektowość, niż "optymalizować" kodem strukturalnym... OO chroni przed błędami, sprzyja testowaniu, oraz wymaga mniej zabiegów pielęgnacyjnych... Nie mówiąc o przejrzystości... Ale to w zasadzie idealny temat na flamewar

A przy okazji Kosiarz... Twoje API byłoby znacznie bardziej przejrzyste w kontekście K, gdyby było zgodne ze standardami nazewnictwa (które znajdziesz na Wiki )

Słyszeli ludzie? Hao rozpoczyna nabór na stanowisko dokumentatora Jeśli nie masz wystarczających umiejętności by pomóc w tworzeniu K, możesz pomóc w dokumentowaniu.


Wiesz, że już próbowałem się mu przyjrzeć nawet starszej wersji i włąśnie są problemy z dostępmen do staminy


Faktycznie. Kiedyś miałem problem z założeniem konta i sta moja propozycja była.



Fajnie że można o tym przeczytać w dokumentacji Ale dodatkowo jest jeszcze jeden atut kAPI. Poprzez pobranie listy kontaktów masz ich listę dokładnie w czasie gdy tego żądasz. W momencie gdy lecisz drugą metodą forem po pozycjach w pewnym momencie ta pozycja może się zmienić. Zwłąszcza gdy for wykonuje długie obliczenia.


Już ktoś mi wysłął taką wiadomość i czytałem tą stronę. Niestety z niektórymi kwestiami trudno było mi się zgodzić przez co uwzględniłem raczej swoje doświadczcenie w nazewnictwie.

Wreszcie mam więcej czasu, żeby dopisać kolejny odcinek telenoweli. Powinieneś chyba Kosiarz nieco spokojniej podchodzić do tematu, bo zaczynasz w nieco zbyt dużym stężeniu uciekać się do złośliwości i nieprzyjemnych przytyków. A po co?

"chciałem poruszyć temat obiektowości w K. I nie mówiłem, że moje rozwiązanie jest fajne" - czy Twoje rozwiązanie jest fajne czy nie - nie oceniam, bo nie o to chodzi (to nie ja byłem kąśliwy w stosunku do kAPI ). Temat niezwiązany z wtyczką powinien trafić w inne miejsce. I trafił.



Ale ja nie mam chęci Ciebie do czegokolwiek przekonywać. Chciałbym tylko zrozumieć o co tak naprawdę Tobie chodzi, bo to ciągle nie jest jasne. Boli, że nie rozumiesz kompletnie co piszę: czy kod obiektowy czy strukturalny - jeden pies. Gdzie tu gloryfikacja kodu strukturalnego, nie wiem.

Będę pisał o sobie co tylko będę chciał, oszczędź mi proszę rozkazów. Mój punkt widzenia przedstawiłem jasno: pisałeś o walorach obiektowego pisania w wątku o tabletce, gdzie obiekty (a dokładniej: obiektowe API K) zupełnie nic by nie dały z racji tego, że tabletka to głównie sztuczki z WinAPI. Twierdzę też, że dobre napisany i udokumentowany kod strukturalny jest tak samo czytelny jak kod obiektowy. Napisałem to tyle razy, że zarzucanie mi "braku jasno przedstawionego punktu widzenia" jest tragikomiczne.


Tak. A drugie zdanie znowu nie jest poparte żadnym argumentem. Ja naprawdę przyjmuję do wiadomości to, że Tobie się wygodniej pracuje (czy pracowałoby) z obiektowym API, ale to nie dowodzi, że jest wygodniejsze.


Kod o większym poziomie skomplikowania wcale nie musi być wydajniejszy (także w użytkowaniu) i to ja Ciebie pytam w takim razie gdzie tu zysk? Złożone relacje między obiektami wymagają spójnego nazewnictwa i dobrej dokumentacji tak samo jak duży kod strukturalny. Lokalność informacji przy obu podejściach można zachować (pisałem o tym) więc wciąż nie trafia to co mówisz, bo wyrażasz swój punkt widzenia poparty własnymi preferencjami a to argumentem nie jest.


Napisałem już, że kodowanie nie jest demokratyczne i nie widzę sensu badania chęci kogokolwiek. Napisałeś, że Ciebie nie przekonałem. Spoko, może faktycznie są ludzie, którzy piszą demokratycznie. Napisałeś, że API jest dla użytkowników tegoż i zgodziłem się z Tobą. Napisałem też, że podejściem obiektowym nie należy uszczęśliwiać na siłę. Nie widziałem by poza Tobą ktoś aż tak naciskał na zmianę API. A wtyczki powstają. Najwyraźniej developerzy potrafią się odnaleźć w obecnym API. Czy fakty nie starczą za odpowiedź?


Możliwe, ale w przypadku K (moim zdaniem) niezwykle ważną kwestią jest właśnie kompatybilność. Wybraź sobie, że nagle przestaje działać kIEview i sprawdź, proszę, ile czekamy na nowe wcielenie tej wtyczki. Bez niej K będzie... trochę upośledzony. Oczywiście z punktu widzenia deva to jest dobre podejście, bo zapewniające lepszą przyszłość, ale K nie jest wyłącznie dla devów a dla ludzi w ogóle.


Tak jak np. zerwanie z Quirks Mode w IE spowodowałoby upadek tylko większości stron intranetowych banków. Jestem i zawsze byłem zwolennikiem całkowitej kompatybilności wstecz. Przecież nie trzeba odrzucać jakiejś funkcji by stworzyć jej lepszy odpowiednik. Naprawdę zupełnie nie rozumiem dlaczego tak się uparłeś na odrzucanie czegokolwiek.


O rany. Pisałem przecież, że nieudokumentowany kod czy obiektowy czy nie jest tak samo ciężki w użyciu. Co Ci dadzą klasy, jak będziesz i tak musiał zgadywać funkcjonalnośc po nazwach (to samo tyczy się kodu strukturalnego). Napisałeś, że Hao mógłby stworzyć szablon dokumentacji klasy i pisałeś o dokumentacji obiektowego API jako o pozytywnym wpływie na rozwój K. Zwróciłem Ci uwagę, że dokumentacja obecnego (strukturalnego) API da Konnektowi tyle samo. Czy to Twoim zdaniem bullshit? Przecież tylko wskazałem, że to żaden argument za API obiektowym.



Kawa : public Uzywka (...)
Herbata : public Uzywka (...)
Kawa.Zaparz(Kawa.Czarna);
Herbata.Zaparz(Herbata.Zielona);
i
Zaparz(UzywkaKawa, Kawa_Czarna);
Zaparz(UzywkaHerbata, Herbata_Zielona);

jakoś nie widzę różnicy w czytelności kodu. W jednym i drugim przypadku IDE po wpisaniu słowa Kawa lub Herbata podpowie co się z nią "wiąże".


Ja też mogę napisać, że nie lubię barszczu, ale czyny temu przeczą - barszcz uwielbiam. Podałem Ci przykłady postawy roszczeniowej: wobec złego Twoim zdaniem obecnego api (należy je zostawić), było to napisane w formie życzenia; wobec zmiany sposobu moderacji, wskazując na zbyt gorliwą (Twoim zdaniem) moderację. Naprawdę mam Ci tłumaczyć słowo pisane? Nie rozbrajaj mnie.


Powinniście zmienić a API a uważam, że w obecnym API szwankuje X i lepiej pracowałoby w postaci Y (przy czym mówię o większym poziomie szczegółowości niż: odrzućcie flagi na rzecz obiektów) nie jest propozycją. Faktyczne propozycje nie budziłyby takiej lawiny bezsensownych dyskusji o sensi istnienia i pozwoliłyby się skupić na niuansach proponowanej przez Ciebie implementacji. Jak wygląda ten wątek - sam wiesz.

O wyższości Windows Forms nad WinApi nie chce mi się pisać - różnice wiekowe i koncepcyjne obu (Windows Forms to wraper) są niewarte klawiatury.


Prawdopodobnie nie rozumiemy się - pewnie łatwiej poznać wnętrzności Konnekta operując na wyższym poziomie abstrakcji (jeśli faktycznie jest tworem dobrze przemyślanym), ale nie Windowsa (a na API graficzne Windowsa zboczyliśmy). Nie wiem, mam ciągnąć ten OT i podawać kobylaste uzasadnienie? Ataki personalne z następnego cytatu pominę.


Tylko zwróć uwagę, że jeśli masz kilka różnych "tworów" opisywanych w programie a ich wszystkie właściwości pobierasz jedną funkcją z flagami, to zamieniając ją tak jak proponujesz na szereg metod, jedna dla każdej właściwości, wcale kodu nie upraszczasz. Móżna podobnie stworzyć makra dla poszczególnych pól i używac ich np. jako Kontakt_GetImie(id);. Naprawdę znów różnica jest niewielka.


Nie pytałem o różnice funkcjonalne tylko praktyczne. Zgadzam się, że obiekty są z założenia bardziej defensywne niż uchwyty, ale w programowaniu strukturalnym także istnieją metody wspomagające wiązanie funkcjonalności z np. uchwytami. Przykładem jest chociażby znienawidzona poza Redmond notacja węgierska.


Te szczegóły są bardzo znaczące, bo piszę aplikacje webowe i dlatego nie używam w pracy ani Windows Forms ani WinApi. ASP.NET jest wyborem marketingowym, wcześniej pisaliśmy także w PHP. W czym się pisze szybciej? W tym, w szym jest więcej odpowiednich bibliotek "na dzień dobry", czyli zależnie od rodzaju projektu.


Nie sklejam - co trochę piszesz coś innego a ja co post pytam o co tak właściwie Tobie chodzi. Od tej pory zakładam, że chodzi Ci o przeankietowanie co kto lubi (już pisałem, że uważam taką ankietę za niepotrzebną, ale wezmę w niej udział).


Odpowiem tak: zamienił stryjek siekierkę na kijek. W kodzie obiektowym musiałbym przeczytać opis 2 metod a w kodzie strukturalnym 2 funkcji (DGet*). Nie wiem w czym przeszkadzają Ci flagi - w kodzie obiektowym musiałeś dopilnować by stworzyć wektor kontaktów a nie czajniczków. "Podobno trzeba najpierw kopiowac bo moze ulec zmianie" można się pozbyć w kAPI, owszem, ale zwróć uwagę, że kAPI to wraper - możesz sobie to zrobić pod spodem. Równie niedoskonałe mogłby być API obiektowe K (mówię o zmianach "w tle"), zresztą jest to AFAIR jeden z punktów "do poprawy". Oba fragmenty kodu znaczą tyle samo (nic) jeśli nie przeczytało się dobrej dokumentacji wspomnianych funkcji/metod.

Cytaty nie działają z powodu dysfunkcji IPB - przy dużej ilości przestaje je parsować odpowiednim wyrażeniem regularnym (nie wiem czemu). Generalnie - norma. Trzeba wtedy część zamienić na /code/ albo podzielić post na dwa.

@hao: dobra dokumentacja libgadu nic nie pomoże jak kod był źle zaprojektowany. Dobry kod broni się sam.

Ktoś próbował napisać aplikację korzystająca z WinApi bez MSDN-a? (KoSiarzPL już chyba o tym wspominał)

twierdzenie, że dobry kod obroni sie sam jest nieco.. przesadzone. Zwłaszcza, jeżeli funkcji jest dużo i to nie tylko ich autorzy maja z owych korzystać.

Czy z obecnej dokumentacji moge dowiedzieć się, jakich flag mogę użyć w klasie cMessage dla pola flag?

No pewnie, że można:

hehe Aule, wystarczyło podać
- znajdz w sdk cMessage, przejdź do opisu "flaga" i spójrz pod "Zobacz również"
- Moduły > Obsługa wiadomosci tekstowych > flagi wiadomości tekstowych

Tak się nauczą jak używać tego SDK

Tylko praktyka... tylko praktyka może pomóc się tego nauczyć

oj uczą się uczą.
Dziękuję za pomoc

A tak z ciekawości spytam. Opis flagi

jest zaczerpnięty z SDK-a czy to właśnie praktyka?

Heh, to wszystko jest z SDK. A ta flaga umożliwia niezauważone usunięcie wiadomości Ustawiasz ją i zwracasz IM_MSG_delete.