🚀 go-pugleaf

> tworzenia UI przyjac: korzystajac z edytora XAML czy tworzac kod.

tworzyc w edytorze i dopomagac sobie kodem tylko tam gdzie trzeba. chyba 
jest jednak latwiej, jesli w ogóle mozna mówic o "latwo" w WPF.

pozdrawiam
Wiktor Zychla 

> Tworze pierwsza aplikacje w WPF i tak sie zastanawiam: jaka metode
> tworzenia UI przyjac: korzystajac z edytora XAML czy tworzac kod.
> Wiem, ze to pierwsze jest szybsze i wigodniejsze, ale nie wszystko
> mozna tam zrobic. Drugie rozwiazanie jest bardziej pracochlonne, ale
> mozliwosci sa nieograniczone (tak przynajmniej twierdza "eksperci").
> W przypadku programu sredniej wielkosc, co lepiej bedzie wykorzystac.
> Oczywiscie prosze wziasc pod uwage, ze program bedzie podlegal zmianom
> (docelowo bedzie tworzony dla roznych klientow, ktorzy moga chciec cos
> dodac lub cos odjac)

Jesli robisz aplikacje pod Windows to zdecydowanie XAML
Jesli planujesz pisac programy pod Windows Phone 7
to ze wzgledu na wydajnosc lepiej wybrac kod.

Jesli dopiero zaczynasz przygode w WPF
to warto spojrzec na MVVM
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
http://mvvmfoundation.codeplex.com/
MVVM kompletnie zmienia sposób myslenia
o tym jak tworzy sie i jak dziala interfejs uzytkowniak,
przejscie z myslenia bazujacego na doswiadczeniach z WinForms jest trudny.

W firmie poszlismy wlasnie w tym kierunku i jak na razie sprawdza sie 
znakomicie.
99% który mielismy w WinForms po prostu znikla, jako calkiem niepotrzebna,
wszystko zalatwia nam databinding.

-- 
____________
Pozdrawiam
Robert Winkler

 

> 99% który mielismy w WinForms po prostu znikla, jako calkiem niepotrzebna,
> wszystko zalatwia nam databinding.

o ile nie mam zamiaru dyskredytowac MVVM jako takiego, to zawsze jakas 
alternatywa - dopowiem pytajacemu, zeby bez kontekstu nie zrozumial tego 
niewlasciwie

otóz - w MVVM o ile nawet jakis kod znika, o tyle pojawia sie nowy kod, 
czasem nawet DUZO tego nowego kodu (klasy viewmodeli).
do tego - databinding w WinForms tez wystepuje i przy dobrze napisanym 
kodzie WinForms MVVM moze nawet spowodowac ze kodu bedzie WIECEJ.

to nie dlatego wiec wybiera sie MVVM (jesli sie wybiera) ze jest mniej kodu, 
tylko z powodu innych jego zalet (o których warto doczytac).

pozdrawiam uprzejmie
Wiktor Zychla 

On Wed, 19 Jan 2011 13:08:32 +0100, "Robert Winkler"
<winkel@NOSPAMpoczta.fm> wrote:

>MVVM kompletnie zmienia sposób myslenia

Moj zmienil -- do dzis nie moge dociec, skad bierze sie owczy ped w
kierunku rozwiazan mniej wydajnych, gdzie odbiorca musi sie mocno
napracowac stosujac pewne modele i zamiast jeszcze ochrzanic
producenta za zawalenie sprawy, to stwierdza, ze to jest postep.

Do czego pije? Eventy oparte na nazwach (au!) pol, brak
wielodziedziczenia zmuszajacy do powielania kodu (trigery
uruchamiajace eventy), jeden kanal transmisji eventow (au!), i brak
kolejkowania/filtrowania zdarzen (bardzo latwo zatkac WPF eventami).

Czesc wynika z konstrukcji C# rzecz jasna, ale tak czy inaczej calosc
przypomina chalture wiazana sznurkami. Nie po to sie w koncu wybiera
C#, zeby cos co powinno byc bledem skladni (dowiazanie do properties z
bledem w nazwie) nie bylo komunikowane nawet bledem w runtime!!! Glupi
Bash mi to nawet by zakomunikowal.

>W firmie poszlismy wlasnie w tym kierunku i jak na razie sprawdza sie 
>znakomicie.
>99% który mielismy w WinForms po prostu znikla, jako calkiem niepotrzebna,
>wszystko zalatwia nam databinding.

Ciesze sie, ze istnieja success stories :-) Ja w kazdym razie patrze
na wydajnosc -- a fakty sa takie, ze 15 lat temu szybciej tworzylem
aplikacje w Delphi, niz dzisiaj w C#/WPF.

Zeby bylo jasne, klne na czym swiat stoi, ale uzywam wlasnie WPF-a. C#
jest juz i tak nieco nieszczesliwy, wiec WPF juz mi i tak nie robi, a
cenie nie jego data binding, ale modulowosc (tj. zagniezdzanie
dowolnych widgetow).

milego dnia, hej


-- 
Moja wyprzedaz wszystkiego: ksiazki, plyty, filmy.
http://www.garaz.pol.pl/

On 20 Sty, 06:52, Maciej Pilichowski
<Pilichowski.MaciejSkasu...@gmail.com> wrote:
> On Wed, 19 Jan 2011 13:08:32 +0100, "Robert Winkler"
>
> <win...@NOSPAMpoczta.fm> wrote:
> >MVVM kompletnie zmienia sposób myslenia
>
> Moj zmienil -- do dzis nie moge dociec, skad bierze sie owczy ped w
> kierunku rozwiazan mniej wydajnych, gdzie odbiorca musi sie mocno
> napracowac stosujac pewne modele i zamiast jeszcze ochrzanic
> producenta za zawalenie sprawy, to stwierdza, ze to jest postep.
>
> Do czego pije? Eventy oparte na nazwach (au!) pol, brak
> wielodziedziczenia zmuszajacy do powielania kodu (trigery
> uruchamiajace eventy), jeden kanal transmisji eventow (au!), i brak
> kolejkowania/filtrowania zdarzen (bardzo latwo zatkac WPF eventami).
>
> Czesc wynika z konstrukcji C# rzecz jasna, ale tak czy inaczej calosc
> przypomina chalture wiazana sznurkami. Nie po to sie w koncu wybiera
> C#, zeby cos co powinno byc bledem skladni (dowiazanie do properties z
> bledem w nazwie) nie bylo komunikowane nawet bledem w runtime!!! Glupi
> Bash mi to nawet by zakomunikowal.
>
> >W firmie poszlismy wlasnie w tym kierunku i jak na razie sprawdza sie
> >znakomicie.
> >99% który mielismy w WinForms po prostu znikla, jako calkiem niepotrzebna,
> >wszystko zalatwia nam databinding.
>
> Ciesze sie, ze istnieja success stories :-) Ja w kazdym razie patrze
> na wydajnosc -- a fakty sa takie, ze 15 lat temu szybciej tworzylem
> aplikacje w Delphi, niz dzisiaj w C#/WPF.
>
> Zeby bylo jasne, klne na czym swiat stoi, ale uzywam wlasnie WPF-a. C#
> jest juz i tak nieco nieszczesliwy, wiec WPF juz mi i tak nie robi, a
> cenie nie jego data binding, ale modulowosc (tj. zagniezdzanie
> dowolnych widgetow).
>
> milego dnia, hej
>
> --
> Moja wyprzedaz wszystkiego: ksiazki, plyty, filmy.http://www.garaz.pol.pl/

mam podobne odczucia względem wpf/mvvm - nie wiem do końca jak jest z
wydajnością, brak błędów z bindowania też można przeżyć.
Ja po prostu nie mogę tego ogarnąć, pomimo przeczytania/przejrzenia
prawie wszystkich książek o wpf, silverlight'cie i mvvm dalej nie wiem
do końca o co chodzi.
Pewne rzeczy, kruczki, sztuczki można znaleźć tylko na jakiś forach,
twitach itp. Tak jakbym miał do czynienia z jakąś technologią obcych
znalezioną w
rozwalonym ufo, a nie biblioteką zrobioną w microsofcie. Nie dość że
temat jest ogromnie obszerny: mvvm, commands, routing, 2 nowe rodzaje
properties, xaml, blend, itd.,
to dokumentacja jest do dupy (jeśli chodzi o trochę bardziej
skomplikowane sprawy). Chyba jestem po prostu za głupi.

Do tego microsoft zachowuje się tak że nie do końca wiadomo jak wpf/
silverlight będzie wyglądał za kilka lat, już teraz dużo ludzi narzeka
że wpf jest traktowany po macoszemu,
cała para idzie w silverlight'a (a w zasadzie to sliverlight'a na
wp7). Szkoda gadać

Pozdrawiam
Arek

On Mon, 14 Feb 2011 16:08:26 -0800 (PST), agend <agend07@gmail.com>
wrote:

>Ja po prostu nie mogę tego ogarn±ć, pomimo przeczytania/przejrzenia
>prawie wszystkich ksi±żek o wpf, silverlight'cie i mvvm dalej nie wiem
>do końca o co chodzi.

To jest akurat proste -- frontend zawsze bazuje na jakis danych.
Zamiast pisac kod w jednym kawalku dzieli sie go wg specjalizacji. Cos
co reprezentuje dane, czyste dane i nic wiecej. Cos co zarzadza tymi
danymi. No i cos co wyswietla te dane. 

>Do tego microsoft zachowuje się tak że nie do końca wiadomo jak wpf/
>silverlight będzie wygl±dał za kilka lat, już teraz dużo ludzi narzeka
>że wpf jest traktowany po macoszemu,
>cała para idzie w silverlight'a (a w zasadzie to sliverlight'a na
>wp7). Szkoda gadać

Microsoft atakuje Jave, a nie tworzy narzedzie pracy tak naprawde.
Dlatego w samym jezyku znajduja sie koszmarne bledy, czy
niedociagniecia. Np. juz od wiekow tluczono -- nie powtarzaj kodu
metoda copy&paste (zasada DRY). A w C# ciagle sie to dzieje.

Niemniej jednak jak przejrzysz inne jezyki oprogramowania, to rece Ci
opadna. Tylko D moze konkurowac z C# jesli chodzi o czysty jezyk, tyle
ze D nie ma poza jezykiem nic -- ksiazek, zaplecza, IDE, GUI, toolkitu
do WWW, etc.

No i zostaje nam garbaty C# :-(

milego dnia, hej
-- 
Moja wyprzedaz wszystkiego: ksiazki, plyty, filmy.
http://www.garaz.pol.pl/

> To jest akurat proste -- frontend zawsze bazuje na jakis danych. Zamiast pisac kod w jednym kawalku dzieli sie go wg specjalizacji. Cos
> co reprezentuje dane, czyste dane i nic wiecej. Cos co zarzadza tymi danymi. No i cos co wyswietla te dane.

to rozumiem, podstawy są przejrzyste, diabeł leży w szczegółach
problem jest taki że przy używaniu MVVM + Prism / Caliburn Micro
rzeczy które były skomplikowane do zrobienia w Windows Forms,
teraz robią się cholernie trudne (przynajmniej dla mnie), oto
przykład : http://blogs.msdn.com/b/dphill/archive/2011/01/23/closable-tabbed-views-in-prism.aspx.
WPF/Silverlight nie było pisane z myślą o MVVM. MVVM zostało sobie
przypomniane (bo to wariacja na temat MVP czy jakoś tak) trochę
później. Jeszcze
później MS zainteresował się MVVM. Efekt jest taki że na prezentacjach
i konferencjach, przy dosyć prostych rzeczach to w miarę fajnie
działa. Ale
jak chcesz zrobić coś większego to zaczyna robić się kosmos - i tego
nie potrafię ogarnąć.

 Żeby oddać sprawiedliwość: WPF / MVVM sprawia że pewne rzeczy stają
się łatwiejsze, kod bardzie czytelny, separation of concerns itd.

> Microsoft atakuje Jave, a nie tworzy narzedzie pracy tak naprawde. Dlatego w samym jezyku znajduja sie koszmarne bledy, czy
> niedociagniecia. Np. juz od wiekow tluczono -- nie powtarzaj kodu metoda copy&paste (zasada DRY). A w C# ciagle sie to dzieje.

Nie rozumiem do końca o czym mówisz. Jak dla mnie to Java musi
gonić .net a nie odwrotnie.
Co możesz zrobić w Javie odnośnie DRY a nie możesz w C#? Linq,
properties, Taski - to w C# kod jest ładniejszy, i bardziej DRY

> Niemniej jednak jak przejrzysz inne jezyki oprogramowania, to rece Ci opadna. Tylko D moze konkurowac z C# jesli chodzi o czysty jezyk, tyle
> ze D nie ma poza jezykiem nic -- ksiazek, zaplecza, IDE, GUI, toolkitu do WWW, etc.

Nie znam D, C# bardzo mi się podoba, tutaj się bardzo postarali, teraz
idę w stronę Python'a
Nie ma języków idealnych, chociaż pewnie c# będzie najbliżej do ideału
z języków statycznie typowanych,

Arek

On Tue, 15 Feb 2011 00:55:21 -0800 (PST), agend <agend07@gmail.com>
wrote:

> Żeby oddać sprawiedliwo¶ć: WPF / MVVM sprawia że pewne rzeczy staj±
>się łatwiejsze, kod bardzie czytelny, separation of concerns itd.

Czy ja wiem. Mi sie podoba to, ze jest XAML i ze moge skladac widgety
w moduly. To drugie bylo juz wczesniej.

Do dzis nie wiem jakie wymagania musi spelniac kolekcja, aby byla
edytowalna w WPF (via data binding). 

>> Microsoft atakuje Jave, a nie tworzy narzedzie pracy tak naprawde. Dlatego w samym jezyku znajduja sie koszmarne bledy, czy
>> niedociagniecia. Np. juz od wiekow tluczono -- nie powtarzaj kodu metoda copy&paste (zasada DRY). A w C# ciagle sie to dzieje.
>
>Nie rozumiem do końca o czym mówisz. Jak dla mnie to Java musi
>gonić .net a nie odwrotnie.

Jezykowo -- tak. Biznesowo -- nie. To Java rzadzi, a C# musi
przedstawic takie cechy, zeby firmom chcialo sie odwracac bieg rzeczy.

>Nie ma języków idealnych, chociaż pewnie c# będzie najbliżej do ideału
>z języków statycznie typowanych,

To, ze nie ma jezykow idealnych nie usprawiedliwia C#, ze jest taki
denny, wez pod uwage zwlaszcza to, jakie jezyki byly wczesniej.

Odnosnie DRY -- gdzie jest u licha typedef? To jest idiotycznie prosta
konstrukcja, ale dzieki niej programista moze napisac 

var x = new FileCounter();

a nie ciagle:

var x = new Dictionary<string,int>();

nie mowiac juz o tym, ze z tego drugiego zapisu mniej wynika niz z
pierwszego.

A takich bolaczek jest mnostwo.

milego dnia, hej
-- 
Moja wyprzedaz wszystkiego: ksiazki, plyty, filmy.
http://www.garaz.pol.pl/

On Tue, 15 Feb 2011 12:02:40 +0100, Maciej Pilichowski wrote:
> Odnosnie DRY -- gdzie jest u licha typedef? To jest idiotycznie prosta
> konstrukcja, ale dzieki niej programista moze napisac 
> 
> var x = new FileCounter();
> 
> a nie ciagle:
> 
> var x = new Dictionary<string,int>();

Duh,

public class FileCounter : Dictionary<string, int>
{
}

I sobie można nawet interfejs rozszerzyć o własne pomoce.

Może jeszcze makr brakuje? I assemblera?

> A takich bolaczek jest mnostwo.

Ta, tam pobiegły -->

Konkrety proszę, a nie dowody nieznajomości/braku 
kompetencji ;-).

P.s. nie zdarza mi się używać C-C/C-V do pisania,
     ale wiadomo, to zależy od osoby/firmy.

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.      http://l3v.eu/

W dniu 2011-02-15 12:27, Łukasz 'Maly' Ostrowski pisze:
> On Tue, 15 Feb 2011 12:02:40 +0100, Maciej Pilichowski wrote:
>> Odnosnie DRY -- gdzie jest u licha typedef? To jest idiotycznie prosta
>> konstrukcja, ale dzieki niej programista moze napisac
>>
>> var x = new FileCounter();
>>
>> a nie ciagle:
>>
>> var x = new Dictionary<string,int>();
>
> Duh,
>
> public class FileCounter : Dictionary<string, int>
> {
> }
>
> I sobie można nawet interfejs rozszerzyć o własne pomoce.

W tym przypadku za bardziej koszerne uwazam:
using FileCounter = Dictionary<string, int>;
    ...
var x = new FileCounter();

-- 
Pozdrawiam
Marcin Kral

> Microsoft atakuje Jave, a nie tworzy narzedzie pracy tak naprawde.
> Dlatego w samym jezyku znajduja sie koszmarne bledy, czy
> niedociagniecia. Np. juz od wiekow tluczono -- nie powtarzaj kodu
> metoda copy&paste (zasada DRY). A w C# ciagle sie to dzieje.
>
Co masz na myśli konkretnie?

> Niemniej jednak jak przejrzysz inne jezyki oprogramowania, to rece Ci
> opadna. Tylko D moze konkurowac z C# jesli chodzi o czysty jezyk, tyle
> ze D nie ma poza jezykiem nic -- ksiazek, zaplecza, IDE, GUI, toolkitu
> do WWW, etc.
>
Wielu uważa, że języki dynamiczne biją na głowę języki takie jak C#.
Np Ruby.

-- 
3P

> Odnosnie DRY -- gdzie jest u licha typedef? To jest idiotycznie prosta
> konstrukcja, ale dzieki niej programista moze napisac
>
> var x = new FileCounter();
>
> a nie ciagle:
>
> var x = new Dictionary<string,int>();
>
> nie mowiac juz o tym, ze z tego drugiego zapisu mniej wynika niz z
> pierwszego.
>
Bez jaj.

To nie ma nic wspólnego z DRY. Równie dobrze można napisać, że bez sensu  
jest pisanie
int x = 10 skoro można by to zapisać krócej
i x = 10;

a powyższy twój przykład to bym raczej zapisał

var fileCounter = new Dictionary<string, int>();

albo odziedziczył, lub zawarł w mojej klasie, Dictionary<string, int>.

-- 
3P

On Tue, 15 Feb 2011 14:23:38 +0100, Marcin Kral wrote:
> 
> W tym przypadku za bardziej koszerne uwazam:
> using FileCounter = Dictionary<string, int>;
>     ...
> var x = new FileCounter();

Oczywiście, ale taki using  ma lokalny scope.

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.      http://l3v.eu/

W dniu 2011-02-15 15:33, Łukasz 'Maly' Ostrowski pisze:
> On Tue, 15 Feb 2011 14:23:38 +0100, Marcin Kral wrote:
>>
>> W tym przypadku za bardziej koszerne uwazam:
>> using FileCounter = Dictionary<string, int>;
>>      ...
>> var x = new FileCounter();
>
> Oczywiście, ale taki using  ma lokalny scope.

Za to działa dla klas sealed... i jest aliasem, a nie nowym bytem. 
Jakkolwiek, jesli potrzeba aliasa -> using; jesli wspolnego interfejsu 
-> interfejs/dziedziczenie.

-- 
Pozdrawiam
Marcin Kral

On Tue, 15 Feb 2011 16:36:14 +0100, Marcin Kral wrote:
> Za to działa dla klas sealed... i jest aliasem, a nie nowym bytem. 
> Jakkolwiek, jesli potrzeba aliasa -> using; jesli wspolnego interfejsu 
> -> interfejs/dziedziczenie.

Absolutna zgoda.

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.      http://l3v.eu/

On Tue, 15 Feb 2011 12:27:11 +0100, Łukasz 'Maly' Ostrowski
<maly@USUNnemo.pl> wrote:

>Duh,
>
>public class FileCounter : Dictionary<string, int>
>{
>}
>
>I sobie można nawet interfejs rozszerzyć o własne pomoce.

To jest obejscie problemu, nie powiem, ze nie dziala, ale obejscie.

>Może jeszcze makr brakuje? 

Brakuje.

> I assemblera?

Mi nie.

>> A takich bolaczek jest mnostwo.
>
>Ta, tam pobiegły -->
>
>Konkrety proszę, a nie dowody nieznajomości/braku 
>kompetencji ;-).

Databinding w WPF -- sprawdzalny w glowie usera, bo ani w czasie
kompilacji, ani w czasie wykonania binding nie jest weryfikowany.

Eventy -- np. OnPropertyChanged -- za kazdym razem trzeba powielac ten
sam kod (wysylanie eventow), bo raz ze odpalanie eventow musi sie
odbywac z poziomu klasy-rodzica, to w C# nie ma wielodziedziczenia.
Mozna np. obejrzec sobie klasy generowane przez SQLMetala, zeby
policzyc ile tam jest realnego kodu, a ile wlasnie powtorek.

Brak foreach (ref ), ktore trzeba rozpisywac albo na wygenerowanie
nowej kolekcji albo iterowanie via for -- w C++ dzieki makrom mialem i
foreacha i foreacha ref (analogie rzecz jasna).

>P.s. nie zdarza mi się używać C-C/C-V do pisania,
>     ale wiadomo, to zależy od osoby/firmy.

W C# zdarza mi sie to b.czesto. Zwlaszcza jesli chodzi o eventy i WPF.

milego dnia, hej

-- 
Moja wyprzedaz wszystkiego: ksiazki, plyty, filmy.
http://www.garaz.pol.pl/

On Tue, 15 Feb 2011 15:25:03 +0100, 3P <3p@noserver.com> wrote:

>
>> Odnosnie DRY -- gdzie jest u licha typedef? To jest idiotycznie prosta
>> konstrukcja, ale dzieki niej programista moze napisac
>>
>> var x = new FileCounter();
>>
>> a nie ciagle:
>>
>> var x = new Dictionary<string,int>();
>>
>> nie mowiac juz o tym, ze z tego drugiego zapisu mniej wynika niz z
>> pierwszego.
>>
>Bez jaj.
>
>To nie ma nic wspólnego z DRY. 

Jak nie ma? Jak bedziesz to gdziesz przekazywal, to ciagle bedziesz
pisal to samo. Wez to poznej refaktoruj.

>Równie dobrze można napisać, że bez sensu  
>jest pisanie
>int x = 10 skoro można by to zapisać krócej
>i x = 10;

??

>a powyższy twój przykład to bym raczej zapisał
>
>var fileCounter = new Dictionary<string, int>();

I jaki parametr bedzie przyjmowala funkcja, do ktorej przekazesz
fileCountera? Dictionary....?

milego dnia, hej
-- 
Moja wyprzedaz wszystkiego: ksiazki, plyty, filmy.
http://www.garaz.pol.pl/

On Tue, 15 Feb 2011 14:23:44 +0100, 3P <3p@noserver.com> wrote:

>> Microsoft atakuje Jave, a nie tworzy narzedzie pracy tak naprawde.
>> Dlatego w samym jezyku znajduja sie koszmarne bledy, czy
>> niedociagniecia. Np. juz od wiekow tluczono -- nie powtarzaj kodu
>> metoda copy&paste (zasada DRY). A w C# ciagle sie to dzieje.
>>
>Co masz na myśli konkretnie?

To, ze zamiast krotko napisac jakas funkcjonalnosc i powiedziec -- "ta
klasa ma te funkcjalnosc" (dziedziczenie) w C# stwierdzono, ze lepiej
bedzie jak user za kazdym razem bedzie sobie ja wpisywal z reki.

Czyli krotko klasy vs. interfejsy. Jedne i drugie sa potrzebne, ale w
C# nie ma wielodziedziczenia, wiec jesli piszesz cos w C# to Twoje
okno musi dziedziczyc po klasie, ale tez i po _interfejsie_
IPropertyNotifyChanged. A to oznacza, ze wysylanie eventow bedziesz za
kazdym razem pisal od nowa.

Albo przeklejal. Obejrzyj dowolny cudzy kod -- ciagle powtorzenia tych
samych fragmetow.

>Wielu uważa, że języki dynamiczne biją na głowę języki takie jak C#.
>Np Ruby.

Jezyki dynamiczne przegrywaja na starcie, wlasnie ze wzgledu na bycie
dynamicznymi.

milego dnia, hej

-- 
Moja wyprzedaz wszystkiego: ksiazki, plyty, filmy.
http://www.garaz.pol.pl/

On Tue, 15 Feb 2011 12:27:11 +0100, Łukasz 'Maly' Ostrowski
<maly@USUNnemo.pl> wrote:

>public class FileCounter : Dictionary<string, int>
>{
>}
>
>I sobie można nawet interfejs rozszerzyć o własne pomoce.
>
>Może jeszcze makr brakuje? 

PS. Dla tych co sie makr boja

#define typedef(name,alias) class name : alias {}

i teraz moglbym pisac

public typedef(FileCounter, Dictionary<string,int>)

Ale pewnie lepiej jest bez makr, bo ktos jeszcze napisze potegowanie
przy pomocy makr i bedzie mial side effects.

milego dnia, hej
-- 
Moja wyprzedaz wszystkiego: ksiazki, plyty, filmy.
http://www.garaz.pol.pl/

On Wed, 16 Feb 2011 06:45:16 +0100, Maciej Pilichowski wrote:

>>public class FileCounter : Dictionary<string, int>
> To jest obejscie problemu, nie powiem, ze nie dziala, ale obejscie.

To nie jest obejście, to jest rozwiązanie syntetycznego
problemu jaki sobie postawiłeś.

>>Może jeszcze makr brakuje? 
> Brakuje.

Wielkie zło języka C, a Tobie tego brakuje. Masz problem.

>> I assemblera?
> Mi nie.

Dwa poprzednie punkty to sarkazm.

> Databinding w WPF -- sprawdzalny w glowie usera, bo ani w czasie
> kompilacji, ani w czasie wykonania binding nie jest weryfikowany.

Nie korzystam z WPF, nie lubie. Więc się nie wypowiem.

> Eventy -- np. OnPropertyChanged -- za kazdym razem trzeba powielac ten
> sam kod (wysylanie eventow), bo raz ze odpalanie eventow musi sie
> odbywac z poziomu klasy-rodzica, to w C# nie ma wielodziedziczenia.
> Mozna np. obejrzec sobie klasy generowane przez SQLMetala, zeby
> policzyc ile tam jest realnego kodu, a ile wlasnie powtorek.

He? Co konkretnie trzeba powielić?

> Brak foreach (ref ), ktore trzeba rozpisywac albo na wygenerowanie
> nowej kolekcji albo iterowanie via for -- w C++ dzieki makrom mialem i
> foreacha i foreacha ref (analogie rzecz jasna).

Bosko. Miałeś makra. To przypomina praktycznie pisanie w Qt,
makro na makrze, wymagany preprocesor, praktycznie własny
dialekt, to jest porażka.

>>P.s. nie zdarza mi się używać C-C/C-V do pisania,
>>     ale wiadomo, to zależy od osoby/firmy.
> 
> W C# zdarza mi sie to b.czesto. Zwlaszcza jesli chodzi o eventy i WPF.

Wymieniłeś tylko eventy i databinding w WPF.

Wcześniej napisałeś "mnóstwo", cztery wyimaginowane 
problemu to już byłoby "cała masa"? ;-).

> PS. Dla tych co sie makr boja
> 
> #define typedef(name,alias) class name : alias {}
> 
> i teraz moglbym pisac
> 
> public typedef(FileCounter, Dictionary<string,int>)

Konkretnie jaką to ma przewagę nad:
public class FileCounter : Dictionary<string, int> {}
? (to jest jakieś 5 znaków różnicy, a tylko zaciemniasz
orginalną intencję).

No chyba że "Super, za pomocą makr mam kompletnie
nieczytelną namiastkę własnego dialektu!"

Jak będzie wyglądał kod błędu jak tam zrobisz literówkę?

Tak jak obok napisał 3P, według Ciebie, najlepiej
jakbyś zamiast:
int x = 12345;
mógł pisać:
i x 12345;

Bo jest krócej!!11111oneeleven ;-). Ale za to jak 
nieczytelnie, i jak bardzo nie wiadomo co miałeś na myśli.

> 
> Ale pewnie lepiej jest bez makr, bo ktos jeszcze napisze potegowanie
> przy pomocy makr i bedzie mial side effects.

Huh? Zawsze jest lepiej bez makr, makra zostały wymyślone
na potrzeby C. Makra to zło.

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.      http://l3v.eu/

On Wed, 16 Feb 2011 06:50:50 +0100, Maciej Pilichowski wrote:
> To, ze zamiast krotko napisac jakas funkcjonalnosc i powiedziec -- "ta
> klasa ma te funkcjalnosc" (dziedziczenie) w C# stwierdzono, ze lepiej
> bedzie jak user za kazdym razem bedzie sobie ja wpisywal z reki.

To ma swój powód,  multiple inheritance rzadko coś wnosi
oprócz skomplikowania.

> Czyli krotko klasy vs. interfejsy. Jedne i drugie sa potrzebne, ale w
> C# nie ma wielodziedziczenia, wiec jesli piszesz cos w C# to Twoje
> okno musi dziedziczyc po klasie, ale tez i po _interfejsie_
> IPropertyNotifyChanged. A to oznacza, ze wysylanie eventow bedziesz za
> kazdym razem pisal od nowa.

Raz, w jednej klasie w hierarchii klas.

> Albo przeklejal. Obejrzyj dowolny cudzy kod -- ciagle powtorzenia tych
> samych fragmetow.

Wklej coś swojego. Bo mi się wydaje że to problem lokalny. ;-).

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.      http://l3v.eu/

> Databinding w WPF -- sprawdzalny w glowie usera, bo ani w czasie
> kompilacji, ani w czasie wykonania binding nie jest weryfikowany.

w czasie kompilacji wywala jakiś błędy, można ustawić w ide,
dla runtime można zrobić ValueConverter i w kodzie sprawdzać wartość,
ustawić breakpoint,
albo ustaw FallbackValue w xaml-u żeby pokazywało że coś jest nie tak

> Eventy -- np. OnPropertyChanged -- za kazdym razem trzeba powielac ten
> sam kod (wysylanie eventow), bo raz ze odpalanie eventow musi sie
> odbywac z poziomu klasy-rodzica, to w C# nie ma wielodziedziczenia.
> Mozna np. obejrzec sobie klasy generowane przez SQLMetala, zeby
> policzyc ile tam jest realnego kodu, a ile wlasnie powtorek.

eventy odpalasz z poziomu klasy rodzica, ale metodę możesz zdefiniować
w przodku,
chyba wszystkie biblioteki do wpf (prism, caliburn, mvvm light) mają
jakąś swoją wersję
ViewModel po której możesz dziedziczyć. Można przeżyć chociaż ludzie
chcieli żeby
wpisać INotifyPropertyChanged do samego języka.

Arek

> var x = new FileCounter();
>
> a nie ciagle:
>
> var x = new Dictionary<string,int>();

tak przy okazji - czy tylko ja wolę jak jest napisane : x = new
Dictionary<string, int>();
od razu wiem o co chodzi,

przy x = new FileCounter() - muszę się zastanawiać, szukać co to kuwa
jest FileCounter() -

Arek

> Brak foreach (ref ), ktore trzeba rozpisywac albo na wygenerowanie
> nowej kolekcji albo iterowanie via for -- w C++ dzieki makrom mialem i
> foreacha i foreacha ref (analogie rzecz jasna).

O co chodzi z tym foreach (ref)?
-- 
3P

On Wed, 16 Feb 2011 08:35:25 +0100, Łukasz 'Maly' Ostrowski
<maly@USUNnemo.pl> wrote:

>To ma swój powód,  multiple inheritance rzadko coś wnosi
>oprócz skomplikowania.

Moze po prostu tego nie ogarniasz. Rozne rzeczy sa dla roznych osob
skomplikowane.

>> Czyli krotko klasy vs. interfejsy. Jedne i drugie sa potrzebne, ale w
>> C# nie ma wielodziedziczenia, wiec jesli piszesz cos w C# to Twoje
>> okno musi dziedziczyc po klasie, ale tez i po _interfejsie_
>> IPropertyNotifyChanged. A to oznacza, ze wysylanie eventow bedziesz za
>> kazdym razem pisal od nowa.
>
>Raz, w jednej klasie w hierarchii klas.

Teraz mnie ubawiles -- rozdwoisz drzewo klas tylko ze wzgledu na
wysylanie eventow. Ok? A teraz z kolei co zrobisz z funkcjonalnoscia
merytoryczna -- copy&paste?

>> Albo przeklejal. Obejrzyj dowolny cudzy kod -- ciagle powtorzenia tych
>> samych fragmetow.
>
>Wklej coś swojego. Bo mi się wydaje że to problem lokalny. ;-).

Zauwazasz powtorzenia kodu czy nie? I tak dla kazdego pola.

To jest kod Microsoftu.



		public int Lok_Id
		{
			get
			{
				return this._Lok_Id;
			}
			set
			{
				if ((this._Lok_Id != value))
				{
					this.OnLok_IdChanging(value);
					this.SendPropertyChanging();
					this._Lok_Id = value;

this.SendPropertyChanged("Lok_Id");
					this.OnLok_IdChanged();
				}
			}
		}
		
public const string Lok_Id_NadrzednaFieldName = "Lok_Id_Nadrzedna";
		[Column(Name="lok_Id_Nadrzedna",
Storage="_Lok_Id_Nadrzedna", DbType="Int",
UpdateCheck=UpdateCheck.Never)]
		public System.Nullable<int> Lok_Id_Nadrzedna
		{
			get
			{
				return this._Lok_Id_Nadrzedna;
			}
			set
			{
				if ((this._Lok_Id_Nadrzedna != value))
				{

this.OnLok_Id_NadrzednaChanging(value);
					this.SendPropertyChanging();
					this._Lok_Id_Nadrzedna =
value;

this.SendPropertyChanged("Lok_Id_Nadrzedna");

this.OnLok_Id_NadrzednaChanged();
				}
			}
		}
		


-- 
Moja wyprzedaz wszystkiego: ksiazki, plyty, filmy.
http://www.garaz.pol.pl/

Dnia 16-02-2011 o 06:47:13 Maciej Pilichowski  
<Pilichowski.MaciejSkasujTo@gmail.com> napisał(a):

> On Tue, 15 Feb 2011 15:25:03 +0100, 3P <3p@noserver.com> wrote:
>
>>
>>> Odnosnie DRY -- gdzie jest u licha typedef? To jest idiotycznie prosta
>>> konstrukcja, ale dzieki niej programista moze napisac
>>>
>>> var x = new FileCounter();
>>>
>>> a nie ciagle:
>>>
>>> var x = new Dictionary<string,int>();
>>>
>>> nie mowiac juz o tym, ze z tego drugiego zapisu mniej wynika niz z
>>> pierwszego.
>>>
>> Bez jaj.
>>
>> To nie ma nic wspólnego z DRY.
>
> Jak nie ma? Jak bedziesz to gdziesz przekazywal, to ciagle bedziesz
> pisal to samo. Wez to poznej refaktoruj.
>
Jak będziesz miał typedef'a to też będziesz pisał to samo wszędzie.
Zmienisz typedef'a będziesz musiał zmienić każdą funkcję.
Zrobisz swoją klasę, zamiast typedef'a to może nic nie będziesz musiał  
zmieniać.

>> Równie dobrze można napisać, że bez sensu
>> jest pisanie
>> int x = 10 skoro można by to zapisać krócej
>> i x = 10;
>
> ??
>
>> a powyższy twój przykład to bym raczej zapisał
>>
>> var fileCounter = new Dictionary<string, int>();
>
> I jaki parametr bedzie przyjmowala funkcja, do ktorej przekazesz
> fileCountera? Dictionary....?
>

To zależy od kodu przecież. Czasem bym przekazał Dictionary, czasem nie.
Na pewno nie korzystałbym z tego do przerzucania po całym systemie.


Pokaż konkretne przykłady kodu, który jest zły/nieczytelny z powodu braków
w języku c#, o których piszesz. Do tego czasu twoje posty są abstrakcyjne.

-- 
3P

On Wed, 16 Feb 2011 12:50:09 +0100, 3P wrote:

>> Brak foreach (ref ), ktore trzeba rozpisywac albo na wygenerowanie
>> nowej kolekcji albo iterowanie via for -- w C++ dzieki makrom mialem i
>> foreacha i foreacha ref (analogie rzecz jasna).
> 
> O co chodzi z tym foreach (ref)?

Chodzi mu o semantyke referencyjna iteracji.

List<int> l = new ...();
foreach(ref int i in l)
   i += 1;

I zmienia się element listy, pomimo że sam jest value-type.

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.      http://l3v.eu/

Dnia 16-02-2011 o 13:31:31 Łukasz 'Maly' Ostrowski <maly@usunnemo.pl>  
napisał(a):

> On Wed, 16 Feb 2011 12:50:09 +0100, 3P wrote:
>
>>> Brak foreach (ref ), ktore trzeba rozpisywac albo na wygenerowanie
>>> nowej kolekcji albo iterowanie via for -- w C++ dzieki makrom mialem i
>>> foreacha i foreacha ref (analogie rzecz jasna).
>>
>> O co chodzi z tym foreach (ref)?
>
> Chodzi mu o semantyke referencyjna iteracji.
>
> List<int> l = new ...();
> foreach(ref int i in l)
>    i += 1;
>
> I zmienia się element listy, pomimo że sam jest value-type.
>

Tak, znalazłem. Rzeczywiście to było mi zawsze potrzebne ;)
-- 
3P

On Wed, 16 Feb 2011 13:12:30 +0100, 3P <3p@noserver.com> wrote:

>Pokaż konkretne przykłady kodu, który jest zły/nieczytelny z powodu braków
>w języku c#, o których piszesz. Do tego czasu twoje posty s± abstrakcyjne.

Dziekuje, ale odpuszczam sobie dyskusje, bo nie jest ona juz od
dluzszego czasu dyskusja. EOT z mojej strony.

-- 
Moja wyprzedaz wszystkiego: ksiazki, plyty, filmy.
http://www.garaz.pol.pl/