W dniu poniedziałek, 25 czerwca 2012 23:37:00 UTC+2 użytkownik AK napisał:

> I badz precyzyjny: pisalem ze "kolejnosc evaluacji operatorow" _o tym samym
priotrytecie_
> jest dowolna.
> Nawiasy w tym przypadku sa opuszczane juz na etapie (umownego) parsingu.

Na etapie (umownego) parsingu nie wiadomo jeszcze, jakiego typu są parametry i w
konsekwencji nie wiadomo, czy przypadkiem te operatory nie są przeciążone.
Opuszczanie nawiasów na tym (umownym) etapie może powodować nie tylko zmiany w
obserwowalnym zachowaniu, ale w ogóle sprawić, że program się nie skompiluje.
Następny krok: szablony.
Ilość przypadków, w których kompilator może to zrobić jest tak mała, że całe zjawisko
raczej nie zasługuje na uogólnione stwierdzenia typu "w C++ jest tak".

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

On Jun 25, 8:41 pm, Edek Pienkowski <e...@g...com> wrote:
> Dnia Mon, 25 Jun 2012 20:30:49 +0100, Bronek Kozicki napisal:
>
> > elementarne - zrób klasę i zamień zmienne lokalne na prywatne pola
> > klasy, a częsci funkcji na funkcje klasy. Potem upraszczaj.
>
> Powiedz od razu, że mam pisać klasy zamiast metod - jest takich metod
> dobre kilka. I nie bardzo wiem, co miałbym upraszczać i dlaczego miałbym
> psuć działający kod

Miałbyś to robić bez psucia.

> - upraszczanie poniżej miminum jak empirycznie
> stwierdzono nie jest najlepszym pomysłem, a metody nie są już do
> uproszczenia. Kopiowanie pól przy rekurencji też mało mnie pociąga.

Jeśli metoda ma trzydzieści zmiennych lokalnych i jest, cytuję, "za
duża", to jesteś daleko od tego minimum.

W ogóle w tym temacie powinieneś zapoznać się z książką Martina
Fowlera "Refactoring: Improving the Design of Existing Code".

do góry

On Jun 25, 9:05 pm, Edek Pienkowski <e...@g...com> wrote:
>
> Ja to mało wydajny jestem, ale już od dawna marudzą, że tool startuje
> aż w 2 minuty, i to pomimo tego, że wcześniej startował w 6. Ciężkie
> życie...

Prawdę mówiąc to takie rzeczy mają raczej znikomy wpływ na ogólną
wydajność. Jeśli czas startu jest problemem, to należy się raczej
zastanowić, czy nie da się tego rozwiązać przez nie wykonywanie
niektórych czynności na starcie (leniwa inicjalizacja).

do góry

Dnia Wed, 27 Jun 2012 02:11:06 -0700, Andrzej Jarzabek napisal:

> On Jun 25, 8:41 pm, Edek Pienkowski <e...@g...com> wrote:
>> Dnia Mon, 25 Jun 2012 20:30:49 +0100, Bronek Kozicki napisal:
>>
>> > elementarne - zrób klasę i zamień zmienne lokalne na prywatne pola
>> > klasy, a częsci funkcji na funkcje klasy. Potem upraszczaj.
>>
>> Powiedz od razu, że mam pisać klasy zamiast metod - jest takich metod
>> dobre kilka. I nie bardzo wiem, co miałbym upraszczać i dlaczego
>> miałbym psuć działający kod
>
> Miałbyś to robić bez psucia.

Nie da się uprościć poniżej minimum bez psucia. Gdyby się dało,
to "hello world" mogłoby uchodzić i za system bankowy i za sztuczną
inteligencję. A tak niestety nie jest.

>
>> - upraszczanie poniżej miminum jak empirycznie stwierdzono nie jest
>> najlepszym pomysłem, a metody nie są już do uproszczenia. Kopiowanie
>> pól przy rekurencji też mało mnie pociąga.
>
> Jeśli metoda ma trzydzieści zmiennych lokalnych i jest, cytuję, "za
> duża", to jesteś daleko od tego minimum.

Pożycz szklaną kulę...

>
> W ogóle w tym temacie powinieneś zapoznać się z książką Martina Fowlera
> "Refactoring: Improving the Design of Existing Code".

Może z 5-10 lat temu to i owszem, pomijając ryzyko stania się
"opinionated". Nie muszę szlifować technikaliów.

Edek

do góry

On Jun 27, 10:21 am, Edek Pienkowski <e...@g...com>
wrote:
> Dnia Wed, 27 Jun 2012 02:11:06 -0700, Andrzej Jarzabek napisal:
[...]
> > Miałbyś to robić bez psucia.
>
> Nie da się uprościć poniżej minimum bez psucia. Gdyby się dało,
[...]
> > duża", to jesteś daleko od tego minimum.
>
> Pożycz szklaną kulę...

Miszczu - piszesz, że masz metodę, która jest "za duża" i że chcesz ją
podzielić, a nawet używasz sformułowania "cokolwiek bym nie chciał
wydzielić" - to sugeruje, że byś jednak coś z niej chciał wydzielić i
nawet masz jakieś pomysły, co to by mogło być. Ja się nie odnoszę do
tego, czy akurat masz w tym momencie rację, że jest za duża i czy masz
rację, że chcesz podzielić - opieram się tylko na tym, co sam piszesz.
Ja mogę tylko powiedzieć, że jeśli metoda ma faktycznie trzydzieści
zmiennych lokalnych to jest bardzo wysoce prawdopodobne, że faktycznie
jest za duża i że można ją podzielić. I w takiej sytuacji "replace
method with method object" jest dobrym wstępem do dalszych
refaktoryzacji.

> > W ogóle w tym temacie powinieneś zapoznać się z książką Martina Fowlera
> > "Refactoring: Improving the Design of Existing Code".
>
> Może z 5-10 lat temu to i owszem, pomijając ryzyko stania się
> "opinionated". Nie muszę szlifować technikaliów.

Sorki, ale jeśli uważasz, że nie da się zejść ze złożonością poniżej
30 zmiennych lokalnych w metodzie, to myślę, że powinieneś jednak się
zapoznać.

do góry

On Wednesday, June 27, 2012 10:14:05 AM UTC+1, Andrzej Jarzabek wrote:
> On Jun 25, 9:05 pm, Edek Pienkowski <e...@g...com> wrote:
> >
> > Ja to mało wydajny jestem, ale już od dawna marudzą, że tool startuje
> > aż w 2 minuty, i to pomimo tego, że wcześniej startował w 6. Ciężkie
> > życie...
>
> Prawdę mówiąc to takie rzeczy mają raczej znikomy wpływ na ogólną
> wydajność.

Ale maja duzy wplyw na "postrzegana wydajnosc".

RW

do góry

Dnia Wed, 27 Jun 2012 04:02:28 -0700, Andrzej Jarzabek napisal:

> On Jun 27, 10:21 am, Edek Pienkowski <e...@g...com>
> wrote:
>> Dnia Wed, 27 Jun 2012 02:11:06 -0700, Andrzej Jarzabek napisal:
> [...]
>> > Miałbyś to robić bez psucia.
>>
>> Nie da się uprościć poniżej minimum bez psucia. Gdyby się dało,
> [...]
>> > duża", to jesteś daleko od tego minimum.
>>
>> Pożycz szklaną kulę...
>
> Miszczu - piszesz, że masz metodę, która jest "za duża" i że chcesz ją
> podzielić, a nawet używasz sformułowania "cokolwiek bym nie chciał
> wydzielić" - to sugeruje, że byś jednak coś z niej chciał wydzielić i
> nawet masz jakieś pomysły, co to by mogło być. Ja się nie odnoszę do
> tego, czy akurat masz w tym momencie rację, że jest za duża i czy masz
> rację, że chcesz podzielić - opieram się tylko na tym, co sam piszesz.
> Ja mogę tylko powiedzieć, że jeśli metoda ma faktycznie trzydzieści
> zmiennych lokalnych to jest bardzo wysoce prawdopodobne, że faktycznie
> jest za duża i że można ją podzielić. I w takiej sytuacji "replace
> method with method object" jest dobrym wstępem do dalszych
> refaktoryzacji.

Tematem było C++sowe func(Some& inOutParam, Some2& outParam), których
nie ma w Javie.

Obawiałem się, że na dużą metodę niektórzy zareagują jak psy Pawłowa.
Ten kod ogólnie nie wymaga grubszej refaktoryzacji, a dodatkowo w zasadzie
jedynymi sensownymi opcjami w przypadku tej metody jest klasa z kodem lub
klasa na dane, czy w zasadzie struktura. Ani jedno ani drugie nie poprawia
czytelności.

>
>> > W ogóle w tym temacie powinieneś zapoznać się z książką Martina
>> > Fowlera "Refactoring: Improving the Design of Existing Code".
>>
>> Może z 5-10 lat temu to i owszem, pomijając ryzyko stania się
>> "opinionated". Nie muszę szlifować technikaliów.
>
> Sorki, ale jeśli uważasz, że nie da się zejść ze złożonością poniżej 30
> zmiennych lokalnych w metodzie, to myślę, że powinieneś jednak się
> zapoznać.

A ja uważam, że jesteś właśnie "opinionated". Coś przeczytałeś, coś
powtarzasz, a niewiele z tego rozumiesz, co niestety widać.

Edek

do góry

Użytkownik "Edek Pienkowski" <e...@g...com> napisał:

> Tematem było C++sowe func(Some& inOutParam, Some2& outParam), których
> nie ma w Javie.

Jak to nie ma w Javie ? Nie rozumiem ? /zastrzegam, ze poczatkuje w Javie/

AK

do góry

Dnia Wed, 27 Jun 2012 13:49:38 +0200, AK napisal:

> Użytkownik "Edek Pienkowski" <e...@g...com> napisał:
>
>> Tematem było C++sowe func(Some& inOutParam, Some2& outParam), których
>> nie ma w Javie.
>
> Jak to nie ma w Javie ? Nie rozumiem ? /zastrzegam, ze poczatkuje w
> Javie/

Poliglofon ze mnie, ale proszę trzymać się tematu.

Edek

do góry

W dniu środa, 27 czerwca 2012 13:49:38 UTC+2 użytkownik AK napisał:

> > Tematem było C++sowe func(Some& inOutParam, Some2& outParam), których
> > nie ma w Javie.
>
> Jak to nie ma w Javie ?

W Javie wszystkie parametry przekazywane sa przez wartość. Nie ma czegoś takiego jak
przekazywanie przez referencję ani też rozróżnialnych trybów in/out/inout.

I zgadzam się, że jest to poważna upierdliwość tego języka.

> /zastrzegam, ze poczatkuje w Javie/

Służymy dalszymi wyjaśnieniami.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry