🚀 go-pugleaf

Rafal <wawrzyniak.r@gmail.com> napisał(a): 

> Nie wiem jak po=B3=B1czy=E6 switch z funkcj=B1. Stworzy=B3em co=B6 
takiego,=
>  a
> dok=B3adniej uzupe=B3ni=B3em funkcj=EA i instrukcj=EA switch jednak co=B6 
j=
> est
> =BCle. Nie mam pomys=B3u w jaki spos=F3b por=F3wna=E6 warto=B6ci 
instrukcji=
>  switch
> w funkcji detectType.
> Prosz=EA o pomoc.
> 
> // Example switch statement. typeof returns the type
> // of the value as a string. For example, the type of
> // a string is 'string', the type of a number is
> // 'number', and the type of an object is 'object'.
> switch (typeof 'foo') {
>       case 'string':
>     // some code
>     // If you don't return in the block, you should
>     // always have a break afterwards.
>     break;
>       case 'number':
>     break;
>       case 'object':
>     break;
>   default:
>     //block
> }
> 
> // Write a function that uses switch statements on the
> // type of value. If it is a string, return 'str'. If it
> // is a number, return 'num'. If it is an object, return
> // 'obj'. If it is anything else, return 'other'.
> function detectType(str, num, obj, other) {
>   if(typeof =3D=3D=3D 'string'){
>     return str;
>   }
>   else if(typeof =3D=3D=3D 'number'){
>     return num;
>   }
>   else if(typeof =3D=3D=3D 'object'){
>     return obj;
>   }
>   else{
>     return other;
>   }
> }



Np tak:


<script>

zm1="aaa";
zm2=123;
var zm3 = new Array();
var zm4;

dT(zm1);
dT(zm2);
dT(zm3);
dT(zm4);

function dT(cos)
{

 z=typeof(cos);

 switch(z)
 {
  case 'string': alert(z); break;
  case 'number': alert(z); break;
  case 'object': alert(z); break;
  default: alert('nic...'); break;
 }
}

</script>

Andrzej.


-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

On Jan 9, 10:25 am, "NKAB -" <n...@NOSPAM.gazeta.pl> wrote:
> Rafal <wawrzynia...@gmail.com> napisa³(a):
>
>
>
>
>
>
>
>
>
>
>
> > Nie wiem jak po=B3=B1czy=E6 switch z funkcj=B1. Stworzy=B3em co=B6
> takiego,=
> >  a
> > dok=B3adniej uzupe=B3ni=B3em funkcj=EA i instrukcj=EA switch jednak co=B6
> j=
> > est
> > =BCle. Nie mam pomys=B3u w jaki spos=F3b por=F3wna=E6 warto=B6ci
> instrukcji=
> >  switch
> > w funkcji detectType.
> > Prosz=EA o pomoc.
>
> > // Example switch statement. typeof returns the type
> > // of the value as a string. For example, the type of
> > // a string is 'string', the type of a number is
> > // 'number', and the type of an object is 'object'.
> > switch (typeof 'foo') {
> >       case 'string':
> >     // some code
> >     // If you don't return in the block, you should
> >     // always have a break afterwards.
> >     break;
> >       case 'number':
> >     break;
> >       case 'object':
> >     break;
> >   default:
> >     //block
> > }
>
> > // Write a function that uses switch statements on the
> > // type of value. If it is a string, return 'str'. If it
> > // is a number, return 'num'. If it is an object, return
> > // 'obj'. If it is anything else, return 'other'.
> > function detectType(str, num, obj, other) {
> >   if(typeof =3D=3D=3D 'string'){
> >     return str;
> >   }
> >   else if(typeof =3D=3D=3D 'number'){
> >     return num;
> >   }
> >   else if(typeof =3D=3D=3D 'object'){
> >     return obj;
> >   }
> >   else{
> >     return other;
> >   }
> > }
>
> Np tak:
>
> <script>
>
> zm1="aaa";
> zm2=123;
> var zm3 = new Array();
> var zm4;
>
> dT(zm1);
> dT(zm2);
> dT(zm3);
> dT(zm4);
>
> function dT(cos)
> {
>
>  z=typeof(cos);
>
>  switch(z)
>  {
>   case 'string': alert(z); break;
>   case 'number': alert(z); break;
>   case 'object': alert(z); break;
>   default: alert('nic...'); break;
>  }
>
> }
>
> </script>
>
> Andrzej.
>
> --
> Wys³ano z serwisu Usenet w portalu Gazeta.pl ->http://www.gazeta.pl/usenet/

Dzięki wielkie,
teraz już wszystko rozumiem

W dniu 2012-01-09 10:25, NKAB - pisze:

>   switch(z)
>   {
>    case 'string': alert(z); break;
>    case 'number': alert(z); break;
>    case 'object': alert(z); break;
>    default: alert('nic...'); break;
>   }

Gdyby break było obligatoryjne, to by go wcale w składni nie było, a 
jego rolę spełniałby następny case lub default (a jeszcze break po 
default - po jakiego grzyba?).
W tym konkretnym przypadku starczy seria case-ów, bez niczego (a 
zwłaszcza break), w ostatnim case zaś ów alert gdyż dla każdego 
wcześniejszego przypadku jest ten sam (i tym razem z break, żeby nie 
wykonać akcji dla default) a potem deafult z alternatywą (już bez 
całkiem zbędnego break).
Naprawdę warto zrozumieć, co to case i break oznacza, a nie traktować je 
bezmyślnie jak znaczniki początku i końca bloku czegoś na kształt "if".

v.

Vax <mail@zepsul.sie> napisał(a): 

> default - po jakiego grzyba?).

> Naprawdę warto zrozumieć, co to case i break oznacza, a nie traktować je 
> bezmyślnie jak znaczniki początku i końca bloku czegoś na kształt "if".
> 

..a bo ja jestem Monk i lubię tak jak napisałem, mnie nie przeszkadza.
Ale masz rację w default break jest zbędne.

Andrzej.


-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

W dniu 2012-01-13 10:47, NKAB - pisze:

>> default - po jakiego grzyba?).
>
>> Naprawdę warto zrozumieć, co to case i break oznacza, a nie traktować je
>> bezmyślnie jak znaczniki początku i końca bloku czegoś na kształt "if".
>>
>
> ..a bo ja jestem Monk i lubię tak jak napisałem, mnie nie przeszkadza.

szkoda tylko, że bierzesz się za "nauczanie" i takim przykładem 
zaszczepiasz komuś początkującemu przeświadczenie, że switch to taki 
"zamiennik serii ifów ze wspólnym elsem".

Monk, poza natręctwem, posiadał inteligencje i zrozumiałby, iż case w 
switch oznacza "jeśli TA wartość pasuje, to OD TEGO MIEJSCA zacznij 
wykonywać kod" - i dalsze sprawdzanie nie jest wykonywane, nawet po 
napotkaniu break, gdyż ten przerywa wykonywanie całego switcha, a nie 
tylko swego case.
Zaś default oznacza po prostu: "wykonaj bezwarunkowo" - nie, nie jakieś 
"gdy nic nie pasowało", ale właśnie "wykonaj zawsze" - to, że zazwyczaj 
się nie wykonuje, to wyłącznie zasługa napotkanego gdzieś wcześniej break.
Co nie oznacza, że break _musi_ wystąpić, może go nie być po jednym lub 
kilku case, może go nie być wcale. Case-y bez break mogą być puste, mogą 
też zawierać jakiś kod. I działa to sensownie - o ile się wie, czym 
naprawdę jest blok switch.

Jeden amator będzie uczył drugiego amatora o tym, co mu się wydaje, 
trzeci napisze na tej "podstawie" jakiś "kurs" z którego inni będą 
cytować... co ja piszę, przecież to się już dzieje - od lat :/

W dniu 2012-01-13 13:08, prof pisze:

>> ..a bo ja jestem Monk i lubię tak jak napisałem, mnie nie przeszkadza.

Jest prawie jak Monk - "prawie" robi różnicę ;)

> Zaś default oznacza po prostu: "wykonaj bezwarunkowo" - nie, nie jakieś
> "gdy nic nie pasowało", ale właśnie "wykonaj zawsze" - to, że zazwyczaj
> się nie wykonuje, to wyłącznie zasługa napotkanego gdzieś wcześniej break.

Niemal dobrze. Niemal, gdyż default jednak oznacza "gdy żaden case nie 
pasuje", co możesz sprawdzić empirycznie, umieszczając sekcję default 
nie na końcu, ale np. na początku, lub pomiędzy innymi case.

Łopatologicznie: obliczane jest wyrażenie w switch i następuje próba 
znalezienia "wejścia" w kod - w pierwszy pasujący case. Gdy klucz nie 
pasuje do żadnych drzwi, używane jest wejście z napisem "default".

Możliwość umieszczenia tego defaulta w dowolnym miejscu, pamiętając o 
tym, że break po nim wcale nie jest obligatoryjny (choć wystąpić może i 
gdy po default są jeszcze jakieś case-y często jest uzasadniony), daje 
jeszcze większą elastyczność i pole do ciekawych manewrów.

Poza tym OK, zarówno w warstwie merytorycznej jak i "socjologicznej" ;)

v.

Vax <mail@zepsul.sie> napisał(a): 

> Niemal dobrze. Niemal, gdyż default jednak oznacza "gdy żaden case nie 
> pasuje", co możesz sprawdzić empirycznie, umieszczając sekcję default 
> nie na końcu, ale np. na początku, lub pomiędzy innymi case.
> 
> Łopatologicznie: obliczane jest wyrażenie w switch i następuje próba 
> znalezienia "wejścia" w kod - w pierwszy pasujący case. Gdy klucz nie 
> pasuje do żadnych drzwi, używane jest wejście z napisem "default".
> 
> Możliwość umieszczenia tego defaulta w dowolnym miejscu, pamiętając o 
> tym, że break po nim wcale nie jest obligatoryjny (choć wystąpić może i 
> gdy po default są jeszcze jakieś case-y często jest uzasadniony), daje 
> jeszcze większą elastyczność i pole do ciekawych manewrów.
> 
> Poza tym OK, zarówno w warstwie merytorycznej jak i "socjologicznej" ;)
> 
> v.

Wyjąłeś mi to z ust.

Switch to własnie lepsze ify, lepsze bo po break
już nie sprawdza się następnych kejsów.

Ten nasz kolega to rzeczywiście jakiś profesor
bo ja do takich pierdół nie przykładam wagi.

Program ma działać szybko i zgodnie z oczekiwaniami
a ten break w default nie ma znaczenia.

Pytający zaś dostał ode mnie jedno z rozwiązań
jego problemu.

Dlaczego profesor nie przedstawił swojego lepszego
rozwiązania tylko kłóci się o pierdoły.
Żeby jeszcze powiedział to coś w stylu
"chciałbym zwrócić uwagę, że...",
"dodam tylko, że..." itp
a tak robi się z wątku kłótliwy flejm.
 
Andrzej.


-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

W dniu 2012-01-16 09:07, NKAB - pisze:

> Switch to własnie lepsze ify, lepsze bo po break
> już nie sprawdza się następnych kejsów.

Wybacz, ale nie wydaje mi się - sprawdzane są wszystkie case, choćby po 
to, by rozstrzygnąć, czy skorzystać  z pierwszego default (sprawdziłem i 
działa jak pisał vax).
Natomiast możliwość wskoczenia w środek kodu i opuszczenia go albo 
przejścia do kolejnej "etykiety" case/default (bez sprawdzania warunku) 
znacznie wykracza poza logikę i funkcjonalność typowych instrukcji 
warunkowych ignorancie. Masz jeszcze bardzo naiwne pojęcie o 
programowaniu, ale bardzo wyrywasz się do "pokazywania" tego, co ci się 
_wydaje_.

> Ten nasz kolega to rzeczywiście jakiś profesor
> bo ja do takich pierdół nie przykładam wagi.

I uczysz pierdół, powstają kolejne pierdoły, które znów "popisują" się, 
tym, czego się nauczyły i potem mamy to co mamy, czyli pierdoły 
wysyłające pierdoły.

> Program ma działać szybko i zgodnie z oczekiwaniami
> a ten break w default nie ma znaczenia.

Program, który ma z założenia mieć "walory edukacyjne" (będący 
odpowiedzią na pytanie zadane na grupie poświęconej językowi) winien być 
napisany z sensem. Sekwencja alert(z);break;break też będzie szybka i 
zgodna z oczekiwaniami i jeszcze bardziej bez sensu.

> Pytający zaś dostał ode mnie jedno z rozwiązań
> jego problemu.

...z parokrotnym powtórzeniem zbędnego kodu.
Jego problemem było zrozumieć działanie switcha, a nie otrzymać 
przykładowy i logicznie bezsensowny (choć działający) kod.

> Dlaczego profesor nie przedstawił swojego lepszego
> rozwiązania tylko kłóci się o pierdoły.

Kto to "profesor"?
Skoro już Vax napisał, że starczy jedno alert(z);break - to po cholerę 
to pisać, nie zrozumiałeś i potrzeba przykładu?
I mam prośbę - nie przekręcaj mi "nicka", bo gotów jestem pomyśleć, że 
strasznie cierpisz z powodu urażonej miłości własnej.

> Żeby jeszcze powiedział to coś w stylu
> "chciałbym zwrócić uwagę, że...",
> "dodam tylko, że..." itp
> a tak robi się z wątku kłótliwy flejm.

To przestań się kłócić - ja wyjaśniłem jak działa switch i bez bicia 
piany przyznaję, że z default nie miałem racji (vax mnie naprostował i 
podał sposób, jak to zweryfikować, sprawdziłem - przyznaje mu rację).
Gdybym był tobą, to bym teraz pieprzył, że "ale wszyscy piszą default na 
końcu a w takim wypadku moja teoria się sprawdza, tzn. wyniki pasują 
tak, jakby była prawdziwa". Ale tobą nie jestem i przyznaje, że 
wyciągnąłem nieprawidłowe wnioski, bo nie wpadło mi do łba, żeby 
sprawdzić "niestandardowe" miejsce default.

Jak na razie to w wątku występuje jeden przemądrzały i bardzo rozżalony 
smarkacz, który przekręca ludziom przydomki i zamiast przyznać, że 
wkleił bezmyślny kod, to dorabia ideologie "a bo ważne, żeby tylko jakoś 
działało" i bije pianę już w trzecim poście - bez żadnych argumentów 
merytorycznych czy czegokolwiek wnoszącego cokolwiek w sprawę 
wyjaśnienia działania konstrukcji switch-case.

Ogarnij się dzieciaku i zacznij gadać na temat lub wcale, zamiast się 
"mścić" na tych, co mieli czelność wykazać, że piszesz głupoty.

Nie byłoby tej dyskusji gdybyś zwyczajnie
napisał sensowny kod i wytłumaczył również mnie
dlaczego mój przykład jest do dupy.

Ale ty nadal wolisz być profesorem, który coś tam gada
ale tak aby nikt nie wiedział o co chodzi.
Daj swój dobry przykład tak aby każdy (nawet ja) to zrozumiał.



Teraz popraw mnie:

x=1;
switch(x)
{
 case 1: "jest 1"; break;
 case 2: "jest 2"; break;           |
 case 3: "jest 3"; break;           | te warunki już nie są sprawdzane
 dafalut: "żadne z powyzszych";     |
}

Andrzej.


-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

W dniu 2012-01-17 08:53, NKAB - pisze:
> Nie byłoby tej dyskusji gdybyś zwyczajnie
> napisał sensowny kod i wytłumaczył również mnie
> dlaczego mój przykład jest do dupy.

przecież Ci odpisał...

> Ale ty nadal wolisz być profesorem

prof. się pisze z kropką na końcu, a Ty najwyraźniej nie potrafisz 
znieść krytyki i z braku lepszych argumentów przekręcasz mu pseudonim.

[ciach bla bla]

> Daj swój dobry przykład tak aby każdy (nawet ja) to zrozumiał.

nie zrozumiałeś co pisał?

> Teraz popraw mnie:

> switch(x)
> {
>   case 1: "jest 1"; break;
>   case 2: "jest 2"; break;           |
>   case 3: "jest 3"; break;           | te warunki już nie są sprawdzane
>   dafalut: "żadne z powyzszych";     |
> }

ja pierniczę, jak dziecku:

switch(x){
  case 1:
  case 2:
  case 3: alert('jest: '+x);break
  default: alert('inna wartość')
}

Pisał po polsku i tak to zrozumiałem i raczej nie dało się zrozumieć 
inaczej.

v.
PS. bij sobie z nim pianę na innej grupie, tu piszmy _merytorycznie_

Vax <mail@zepsul.sie> napisał(a): 

> nie zrozumiałeś co pisał?
> 






Gdybym wiedział to nie odzywałbym się.





> 
> ja pierniczę, jak dziecku:
> 
> switch(x){
>   case 1:
>   case 2:
>   case 3: alert('jest: '+x);break
>   default: alert('inna wartość')
> }
> 
> Pisał po polsku i tak to zrozumiałem i raczej nie dało się zrozumieć 
> inaczej.
> 


O!

Teraz to już wiem o co chodzi.

Ale zuważ, ze ten jego przykład praktycznie nie wykorzystuje
tego co nalepsze w tym swiczu czyli szybki wyskok po napotkaniu
spełnionego warunku. Dlatego jako pierwsze powinny być warunki,
które najczęściej bedą obsługiwane, a więc jak będzie więcej do
sprawdzania numeryków to pierwszy powinien być warunek sprawdzający
numeryki itd.

Default to warunek wyłacznie dla sytuacji awaryjnych i w zasadzie
bardzo rzadko powinien być wykorzystywany przez aplikację,
naczęściej generuje on jakiś komunikat (np pani kasia wpisała złe
konto ksiegowe), dlatego dla mnie ten break w defalut ma małą
szkodliwość społeczną, czyli pierdołą, ale dla porawności
a raczej profesjonalizmu nie powinno tam być tego brejka
co od razu przyznałem.

Te alerty w każdym warunku to sugestia, że na ogół wywołuje się tam
jakieś funkcje, które dalej mogą robić coś z tym cosiem.

Ja dałem swój przykład pisany z palca bez zastanawiania
a koledzy powinni dać swoje przykłady na zasadzie:
"to pozwolę sobie poprawić twój kod..." no i oczywiście
zamiast słów dać poprostu ten kod, właśnie jak dziecku.


A tak to wyszło jak u tego trepa Maciarewicza - on zarzuca,
on daje do prokuratora - a sam by idiota pojechał do ruskich
zabrał im te dowody, wrak i wszytko co chce, albo przedstawił dowody,
że generała nie było kokpicie. Tylko po co to wszystko?

Andrzej.


-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

W dniu 2012-01-18 10:08, NKAB - pisze:
> Vax<mail@zepsul.sie>  napisał(a):
>
>> nie zrozumiałeś co pisał?
>
> Gdybym wiedział to nie odzywałbym się.

ale ja pisałem dokładnie to samo:
"W tym konkretnym przypadku starczy seria case-ów, bez niczego (a 
zwłaszcza break), w ostatnim case zaś ów alert gdyż dla każdego 
wcześniejszego przypadku jest ten sam (i tym razem z break, żeby nie 
wykonać akcji dla default) a potem deafult z alternatywą (już bez 
całkiem zbędnego break)."

>> switch(x){
>>    case 1:
>>    case 2:
>>    case 3: alert('jest: '+x);break
>>    default: alert('inna wartość')
>> }

> Teraz to już wiem o co chodzi.
>
> Ale zuważ, ze ten jego przykład praktycznie nie wykorzystuje
> tego co nalepsze w tym swiczu czyli szybki wyskok po napotkaniu
> spełnionego warunku.

Jak to nie? W trzecim przypadku, który zachodzi także dla drugiego i 
pierwszego. Wykorzystuje praktycznie i logicznie. Sam zresztą to samo 
pisałem. On za to namieszał z teorią n/t default, która sprawdzi się dla 
default na samym końcu i mimo częściowego "sprawdzania się" jest tylko 
teorią a nie faktycznym sposobem działania switch.

A czy "szybki wyskok" to jest "to co najlepsze" w switch, to bym nie 
powiedział, raczej najpowszechniejsze i niestety dla większości jedyne. 
Ot, taki zamiennik else-ifów. Otóż nie, możliwości są dużo większe.

[...]

> Default to warunek wyłacznie dla sytuacji awaryjnych i w zasadzie
> bardzo rzadko powinien być wykorzystywany przez aplikację,

To chyba w Twej twórczości. Jak sama nazwa wskazuje, jest to działanie 
domyślne, gdy np. nie nastąpią sytuacje wyjątkowe, wymagające wykonania 
jakich specjalnych akcji.

Dla sytuacji A,B oraz trzeba w pewien sposób przygotować dane, dla C 
_dodatkowo_ wykonać wpis do logu, dla X w ogóle zrobić coś innego, a dla 
50-ciu pozostałych przypadków zachować się standardowo:

switch(sytuacja){
  case'X':cos_zupelnie_innego();break
  case'C':loguj()
  case'A':
  case'B':preparuj()
  default:standard()
}

czy taki _typowy_ kontroler wykracza poza Twą wyobraźnię?
Ew. w takim zapisie:

switch(sytuacja){
  case'C':loguj()
  case'A':
  case'B':preparuj()
  default:standard();break
  case'X':cos_zupelnie_innego()
}

Zgaduję, że raczej się nie spotykałeś...

> naczęściej generuje

O tak, materiału porównawczego zapewne masz tyle, by uznać go za 
reprezentatywny. Wybacz, ale twórczość amatorska i kursy dla opornych 
pisane przez przypadkowe osoby się nie liczą.

[...]

> Te alerty w każdym warunku to sugestia, że na ogół wywołuje się tam
> jakieś funkcje, które dalej mogą robić coś z tym cosiem.

Te alerty i break na końcu każdej linii sugerują, że uważasz ja za 
niezbędny element składniowy, na podobieństwo średnika, co w obu 
przypadkach jest nieprawdą.
W tym wypadku pokazałeś nie "jakieś funkcje" ale powtórzoną bez sensu 
kilkukrotnie takąż samą instrukcję, za to nie pokazałeś, co czyni break 
i czy mogło by go czasem nie być.
Czyli "zniknąłeś" sytuację "dla wartości A lub B lub C wykonaj to samo", 
błędnie sugerując, że każdy przypadek _należy_ obsłużyć indywidualnie.

> Ja dałem swój przykład pisany z palca bez zastanawiania

Ja też często pisze z palca, ale nigdy bez zastanawiania. Gorąco polecam.

> a koledzy powinni dać swoje przykłady na zasadzie:

Nie ucz kolegów, co powinni, pierwiej sam zacznij się pisać "z 
zastanowieniem" - choćby chwilowym. To nie jest grupa o pierdołach, ale 
dla niektórych źródło wiedzy, miejsce nauki.

> "to pozwolę sobie poprawić twój kod..." no i oczywiście
> zamiast słów dać poprostu ten kod, właśnie jak dziecku.

Niezrozumienie frazy "starczy seria pustych case-ów, w ostatnim case 
alert i break, potem default dla pozostałych" raczej najlepiej o Tobie 
nie świadczy ;)

> A tak to wyszło jak u tego trepa Maciarewicza (...)

kuźwa, może przynajmniej tu obywać się może bez polityki?

v.

Vax <mail@zepsul.sie> napisał(a): 


Lubię cię bo lubię praktyków, nie lubię gadaczy.
Gdyby krytykanci dali kod nie byłoby kłótni a rzeczowa dyskusja
na konkretnych przykładach. Gdyby amerykanie byli takimi gadaczami
jak my to byliby gorsi od nas. Tam jest zasada pokaż co zrobiłeś.




> czy taki _typowy_ kontroler wykracza poza Twą wyobraźnię?
> Ew. w takim zapisie:
> 
> switch(sytuacja){
>   case'C':loguj()
>   case'A':
>   case'B':preparuj()
>   default:standard();break
>   case'X':cos_zupelnie_innego()
> }
> 
> Zgaduję, że raczej się nie spotykałeś...
> 

No aż taki to ja nie jestem (np. w kwota słownie).




> > naczęściej generuje
> 
> O tak, materiału porównawczego zapewne masz tyle, by uznać go za 
> reprezentatywny. Wybacz, ale twórczość amatorska i kursy dla opornych 
> pisane przez przypadkowe osoby się nie liczą.
> 

Dla amatorów startujących bardzo się liczą.
Naucz przdszkolaka liczyć przy pomocy ułamków a nie patyczków.

Tu na grupie liczy się prostota i komunikatywność na poziomie
przedszkolaka. Tu każdy ma prawo się pomylić i dobrze, gdy ktoś
tą pomyłkę zauważy i skoryguje. Tu ważny jest też język pozbawiony
agresji, bo agresja jest destrukcyjna (stąd ten polityczny akapit).
Gdyby kolega nie rżnął nieomylnego bufona to nie byłoby sprawy.

Ja chociaż zawodowo programuję i zarabiam niemałe pieniądze,
obijając się całe dnie (dzierżawa programów),
to jestem programistą amatorem, nie kończyłem żadnych studiów
informatycznych a jedynie technikum elektryczne.

Klientów mam tylko dlatego, że moje programy są proste, ergonomiczne,
zrozumiałe dla każdego, nie wymnagają kursów obsługi, są niezawodne
bo proste.






> > Te alerty w każdym warunku to sugestia, że na ogół wywołuje się tam
> > jakieś funkcje, które dalej mogą robić coś z tym cosiem.
> 
> Te alerty i break na końcu każdej linii sugerują, że uważasz ja za 
> niezbędny element składniowy, na podobieństwo średnika, co w obu 
> przypadkach jest nieprawdą.

> W tym wypadku pokazałeś nie "jakieś funkcje" ale powtórzoną bez sensu 
> kilkukrotnie takąż samą instrukcję, za to nie pokazałeś, co czyni break
> i czy mogło by go czasem nie być.


nadrabiam niedróbkę:


<script>


zn='';
z='ab';

switch(z)
{
 case z: if(z.substring(0,1)=='a')zn="lit-a";break;
 case z: if(z.substring(1,2)=='b')zn="lit-b";
}

alert('zn='+zn);


</script>

Nie wiem czy do końca to dobry przykład ale z palca.



> Czyli "zniknąłeś" sytuację "dla wartości A lub B lub C wykonaj to samo",
> błędnie sugerując, że każdy przypadek _należy_ obsłużyć indywidualnie.


Tak aż do tego wyjaśnienia to traktowałem
bo jest to oczywiste standardowe i wystarczające.




Jedno mnie tylko zastanawia dlaczego nie WY nie daliście
koledze rozwiązanie tylko ja amator.

Czy to nie dlatego ja mam klientów, bo z nadętymi informatykami
ciężko i bardzo drogo się współpracuje?

Andrzej.


-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

W dniu 2012-01-20 10:34, NKAB - pisze:

>>> naczęściej generuje
>>
>> O tak, materiału porównawczego zapewne masz tyle, by uznać go za
>> reprezentatywny. Wybacz, ale twórczość amatorska i kursy dla opornych
>> pisane przez przypadkowe osoby się nie liczą.
>>
>
> Dla amatorów startujących bardzo się liczą.
> Naucz przdszkolaka liczyć przy pomocy ułamków a nie patyczków.

- Drogie dzieci, w naturze i w życiu _najczęściej_ występują liczby 1, 
2, 3, 4, 5, 6, 7, 8, 9 i 10. Np. Ania ma 3 gruszeczki, a Andrzejek ma 4 
latka.
- Psze pani, psze pani, a pani ile ma lat?
- A ja, to jestem wyjątkiem.
- A ile dzieci jest w przedszkolu?
- Nasze przedszkole też jest wyjątkowe.
- A Ania zjadła już pół gruszki, to ile teraz ma? I ile dni ma rok?
- Won do kąta gówniarzu, ale to już!!!

> Tu na grupie liczy się prostota i komunikatywność na poziomie
> przedszkolaka.

Rozumiem, już się pakuję i wynoszę. Przez te kilka lat, gdy mnie nie 
było, jakoś bardzo to miejsce zdziecinniało. Ale żeby aż przedszkole...

> Tu każdy ma prawo się pomylić i dobrze, gdy ktoś
> tą pomyłkę zauważy i skoryguje.

Jak widać nie dobrze, bo niektórzy nie potrafią się pogodzić z krytyką 
;p A racja - w przedszkolu dzieci nie należy krytykować, ale chwalić, 
chwalić, motywować i ew. delikatnie naprowadzać. To takie pedagogiczne.
Nie ważne, że robią głupoty, ważne, żeby pasji nie zabić.
No litości.

> Tu ważny jest też język pozbawiony
> agresji, bo agresja jest destrukcyjna (stąd ten polityczny akapit).
> Gdyby kolega nie rżnął nieomylnego bufona to nie byłoby sprawy.

Nie zauważyłem, żeby prof nie umiał się przyznać do błędu, ani by bronił 
przegranej sprawy. Chyba, że piszesz o innym uczestniku dyskusji?
Tylko dlaczego w trzeciej osobie?
Zauważ, że jeśli chcieć być uczciwym, to właśnie Ty strasznie przeżywasz 
krytykę i wyjeżdżasz z adpersonami.

> Ja chociaż zawodowo programuję i zarabiam niemałe pieniądze,
> obijając się całe dnie (dzierżawa programów),
> to jestem programistą amatorem, nie kończyłem żadnych studiów
> informatycznych a jedynie technikum elektryczne.

To tym bardziej mógłbyś powstrzymać się od udzielania "dobrych rad" 
innym amatorom. Naczyta się jakiś młody durnot o informatyce i zapadną 
mu w pamięć - niby lepiej, niż naczytać się durnot od "miszczów 
kierownicy" w temacie prowadzenia, ale też szkodzi.
Masz przykład na sobie - skądś przyswoiłeś jakąś wypaczoną wizję switcha 
i puszczasz głupoty dalej (udając znawcę - wszak kto się nie zna, to za 
uczenie innych się nie bierze, nie?).

> Klientów mam tylko dlatego, że moje programy są proste, ergonomiczne,
> zrozumiałe dla każdego, nie wymnagają kursów obsługi, są niezawodne
> bo proste.

Nie. Klientów masz dlatego, że ich nie obchodzi Twój kod, ale to, że 
działa. Możesz traktować switcha jako "inny zapis elseifów", możesz 
uważać (jak wcześniej prof), że default się wykonuje zawsze i gdy tylko 
stosować go będziesz na końcu (a to można inaczej?! ojej) to mimo, że 
pojęcie autora o programowaniu będzie błędne i naiwne, to programy będą 
działać. Kartografia dobrze się miała w czasach "gdy Ziemia była jeszcze 
płaska" a zaćmienia słońca trafnie przewidywano na długo przed Kopernikiem.
U mnie z powtórzeniem tego samo w trzech case _po_kolei_ test 
rekrutacyjny byś oblał. I nie za rozwlekłość kodu.
A jakbyś jeszcze się pokrętnie tłumaczył, że uczyniłeś tak specjalnie, 
żeby było "bardziej zrozumiale" to byś zarobił jeszcze minusa za 
traktowanie innych jak idiotów, nie rozumiejących, co znaczy słowo "break".

Widzisz, _proste_, "ergonomiczne" i skuteczne, to były wozy drabiniaste.
Ale spokojnie, na taki transport też klientów znajdziesz, ich nie 
interesuje czym i jak, ale żeby było dowiezione.

> nadrabiam niedróbkę:
>
>
> <script>
>
>
> zn='';
> z='ab';
>
> switch(z)
> {
>   case z: if(z.substring(0,1)=='a')zn="lit-a";break;
>   case z: if(z.substring(1,2)=='b')zn="lit-b";
> }

no, tożeś nadrobił... "case z" dwukrotnie, nono... ;)
Ten drugi to się na bank wykona.

Ale widzę, że odkryłeś (przypadkiem), że case nie musi być stałą.
Np.:

z=1
a=1
switch(z){
  case a++:
  case a++:
  case a++:alert('trafiony')
}
alert(a)

przetestuj dla kolejnych naturalnych wartości z.

a potem wersja "przedszkolaczek":

z=1
a=1
switch(z){
  case (alert('raz'),a++):
  case (alert('dwa'),a++):
  case (alert('trzy'),a++):break
  default:alert('nie umiem dalej...');
}

analogicznie, dla kolejnych naturalnych z.

Ze zrozumieniem "jak to działa" nie będzie chyba problemu? ;)
Zaiste, ciekawe, dlaczego dla z=2 alertuje się "raz" i "dwa" ale nie 
"trzy" - przecież nie ma break? Na dobrą sprawę mógłby być, nie ma go 
"dla zmyły" ;D

Mam nadzieję, że teraz rozumiesz, czym się różni programista od prostego 
kodera. I wcale nie chodzi o to, że programiści tak piszą. Oni wiedzą, 
że tak się da i jak to będzie działać. Raz na jakiś czas się przydaje, 
by nie komplikować zadania "prostotą".

(...)

> Tak aż do tego wyjaśnienia to traktowałem
> bo jest to oczywiste standardowe i wystarczające.

Dla kogoś z małymi aspiracjami "switch to taki inny zapis else-if" może 
i jest wystarczające. Tylko po co zaniżać poziom niegdyś świetnej grupy?

> Jedno mnie tylko zastanawia dlaczego nie WY nie daliście
> koledze rozwiązanie tylko ja amator.

Bo nie jest mym obowiązkiem udzielanie odpowiedzi.
Natomiast jest mym prawem prostowanie czegoś mało mądrego, jeżeli mam 
taki kaprys. Za drugiego się nie wypowiadam.

> Czy to nie dlatego ja mam klientów, bo z nadętymi informatykami
> ciężko i bardzo drogo się współpracuje?

Na jakiej podstawie uważasz, że zarabiasz "niemałą kasę" i masz "mnóstwo 
klientów" a _inni_nie_? I kto tu jest *nadęty*?
Po raz kolejny zarzucasz innym własne przypadłości.

Mogło by się okazać, że Twoi wszyscy klienci przynoszą mniej kasy, niż 
czyjś jeden. Choć nie sądzę, by ktokolwiek okazał się takim bucem, by na 
grupie o programowaniu próbować epatować zarobkami, czy innymi 
_słabo_weryfikowalnymi_ chełpliwymi przechwałkami o sukcesach zawodowych.

To, że "programujesz" jak przedszkolak, nie implikuje tego, że musisz 
się zachowywać jak przedszkolak.

Chyba straciłem ochotę na dalszą dyskusję.

v.

Vax pisze:
> W dniu 2012-01-09 10:25, NKAB - pisze:
> 
>>   switch(z)
>>   {
>>    case 'string': alert(z); break;
>>    case 'number': alert(z); break;
>>    case 'object': alert(z); break;
>>    default: alert('nic...'); break;
>>   }
> 
> Gdyby break było obligatoryjne, to by go wcale w składni nie było, a 
> jego rolę spełniałby następny case lub default (a jeszcze break po 
> default - po jakiego grzyba?).

Żeby kod wyglądał syntaktycznie poprawniej :P
To żeby wywołać trochę zamieszania oraz krytyki
(pod moim adresem of course)
to ja w zależności od potrzeb robię tak:

<?php
private function checkpermissions($idissue) {
switch ($thiscall) {
case 'contextmenu':
   // OK: PERMISSIONS - everybody can show context menu
   return true;
break;
case 'relations':
   if ($this->USERPERMISSIONS[...inline_ciach...]) {
     // OK: PERMISSIONS - manage_issue_relations=1 => can manage issue 
relations
     return true;
   } else {
     return false;
   }
break;
case 'reply':
   if ($this->USERPERMISSIONS[...inline_ciach...]) {
     // OK: PERMISSIONS - edit_issues=1 => can edit issues
     return true;
   } else {
     return false;
   }
break;
case 'edit':
   if ($this->USERPERMISSIONS[...inline_ciach...]) {
     // OK: PERMISSIONS - edit_issues=1 => can edit issues
     return true;
   } else {
     return false;
   }
break;
case 'move':
   if ($this->USERPERMISSIONS[...inline_ciach...]) {
     // OK: PERMISSIONS - move_issues=1 => can move issues
     return true;
   } else {
     return false;
   }
break;
case 'destroy':
   if ($this->USERPERMISSIONS[...inline_ciach...]) {
     // OK: PERMISSIONS - delete_issues=1 => can delete issues
     return true;
   } else {
     return false;
   }
break;
case 'issuesshow':
default:
   if ($this->USERPERMISSIONS[...inline_ciach...]) {
     // OK: PERMISSIONS - view_issues=1 => can view issues
     return true;
   } else {
     return false;
   }
break;
}
return true;
}

?>

Zwróćcie uwagę na ostatni return true w funkcji,
który z racji obecności w switch warunku default,
a w nim z kolei return, który zawsze się wykona,
to ostatni return jest zbędny, ale jest ;)


> W tym konkretnym przypadku starczy seria case-ów, bez niczego (a 
> zwłaszcza break), w ostatnim case zaś ów alert gdyż dla każdego 
> wcześniejszego przypadku jest ten sam (i tym razem z break, żeby nie 
> wykonać akcji dla default) a potem deafult z alternatywą (już bez 
> całkiem zbędnego break).
> Naprawdę warto zrozumieć, co to case i break oznacza, a nie traktować je 
> bezmyślnie jak znaczniki początku i końca bloku czegoś na kształt "if".
> 
> v.

W dniu 2012-01-20 13:52, PawelS pisze:
> <?php
> private function checkpermissions($idissue) {
> switch ($thiscall) {
> case 'contextmenu':
> // OK: PERMISSIONS - everybody can show context menu
> return true;
> break;

Dzieci, z tego pana nie bierzcie przykładu.

W dniu 2012-01-20 13:52, PawelS pisze:

>> Gdyby break było obligatoryjne, to by go wcale w składni nie było, a
>> jego rolę spełniałby następny case lub default (a jeszcze break po
>> default - po jakiego grzyba?).
>
> Żeby kod wyglądał syntaktycznie poprawniej :P

Dupatam. Ten break coś oznacza. Jego obecność powoduje inne działanie 
niż jego brak.
Tak jak średnik po pętli for(....); coś znaczy (i zdarzało mi się go 
użyć) mimo, że komuś może się wydawać syntaktycznie niepoprawny :)
Natomiast flash usiłował mnie prostować, że zapis if(a=!b) to na bank 
miało być if(a!=b) - głupol ;)

> To żeby wywołać trochę zamieszania oraz krytyki
> (pod moim adresem of course)
> to ja w zależności od potrzeb robię tak:
>
> <?php

Chyba Ci się grupy pop* ;)
Niniejszym krytyce stało się zadość.

v.
PS. a wycięty kod był fe.

W dniu 2012-01-20 22:01, Vax pisze:

> Natomiast flash usiłował mnie prostować, że zapis if(a=!b) to na bank
> miało być if(a!=b) - głupol ;)

a może na odwrót... nie pamiętam, ale czepiał się poprawnego zapisu, 
upierdliwie sugerując swoją wersję przy każdej kompilacji :)

v.

Vax, prosze cię...

kod:

 switch(z)
 {
  case 'string':
  case 'number':
  case 'object': alert(z);break;
  default: alert(z);
 }


ja bym zastąpił:

 if(z=='string' || z=='number' || z=='object')
  alert('jest w if='+z);
 else
  alert('jest w else='+z);





A po zastanowieniu, może to dzieciom pokaże - jak działa ta instrukcja:

switch(1)
{
 case 1:alert("jest w case 1");
 case 1:alert("jest w case 2"); break;
 case 1:alert("jest w case 3");
}


Jak dzieci widzicie wszystkie trzy warunki są spełnione.
Gdyby break nie działał to były by trzy alerty.
Puste kejsy nie mają sensu.

Już wyczerpałem temat i nie zabieram głosu w tej sprawie.

Andrzej.


-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

W dniu 2012-01-23 09:21, NKAB - pisze:
[...]

A ja dodam tylko tyle, że można sobie przetestować szybkość switch-a, 
if-a i ternary:

http://jsperf.com/ternary-vs-if-vs-switch

Ogólnie mi wyszło, że switch jest najwolniejszy :/

-- 
Cezary Tomczyk

Vax pisze:
> W dniu 2012-01-20 13:52, PawelS pisze:
> 
>>> Gdyby break było obligatoryjne, to by go wcale w składni nie było, a
>>> jego rolę spełniałby następny case lub default (a jeszcze break po
>>> default - po jakiego grzyba?).
>>
>> Żeby kod wyglądał syntaktycznie poprawniej :P
> 
> Dupatam. Ten break coś oznacza. Jego obecność powoduje inne działanie 
> niż jego brak.
> Tak jak średnik po pętli for(....); coś znaczy (i zdarzało mi się go 
> użyć) mimo, że komuś może się wydawać syntaktycznie niepoprawny :)
> Natomiast flash usiłował mnie prostować, że zapis if(a=!b) to na bank 
> miało być if(a!=b) - głupol ;)
> 
>> To żeby wywołać trochę zamieszania oraz krytyki
>> (pod moim adresem of course)
>> to ja w zależności od potrzeb robię tak:
>>
>> <?php
> 
> Chyba Ci się grupy pop* ;)

Jeśli sobie życzysz mogę przepisać wklejony kod do JS.

> Niniejszym krytyce stało się zadość.
> 
> v.
> PS. a wycięty kod był fe.

Bądź łaskaw zaszczycić mnie swoim pięknym kodem.
Potomni będą mogli od Ciebie się uczyć ;)

W dniu 2012-01-23 11:59, PawelS pisze:

> Bądź łaskaw zaszczycić mnie swoim pięknym kodem.

a ile chcesz mu zapłacić?

> Potomni będą mogli od Ciebie się uczyć ;)

Potomni już mogą, a Ty chcesz, żeby za Ciebie poprawiać.

case 'cokolwiek1':return $this->USERPERMISSIONS[...blabla1...];
case 'cokolwiek2':return $this->USERPERMISSIONS[...blabla2...];
case 'cokolwiek3':return $this->USERPERMISSIONS[...blabla3...];
default:return $this->USERPERMISSIONS[...blabla...];

ode mnie masz za free ;P

gdybyś jeszcze nie robił [...inline_ciach...] to jeszcze mogło by się 
okazać, że cały ten switch jest zbędny.

W dniu 2012-01-23 09:21, NKAB - pisze:

> ja bym zastąpił:
>
>   if(z=='string' || z=='number' || z=='object')
>    alert('jest w if='+z);
>   else
>    alert('jest w else='+z);

Owszem, ten konkretny kod. Ale teraz kręcimy się wokół switch.

> A po zastanowieniu, może to dzieciom pokaże - jak działa ta instrukcja:
>
> switch(1)
> {
>   case 1:alert("jest w case 1");
>   case 1:alert("jest w case 2"); break;
>   case 1:alert("jest w case 3");
> }
>
> Jak dzieci widzicie wszystkie trzy warunki są spełnione.

A dzieci na to: pitolisz bez sensu, bo po spełnieniu pierwszego żaden 
inny nie będzie sprawdzany, więc czy będzie ich trzy czy trzydzieści, to 
nie ma znaczenia, bo kod się będzie wykonywał ignorując warunki, a 
przerwać to go może np. break.

> Gdyby break nie działał to były by trzy alerty.

Amerykę odkryłeś! Break znaczy tu "przerwij" - e-u-re-ka!

> Puste kejsy nie mają sensu.

W Twoim wypadku nie mają sensu.
W innych mają sens zarówno case bez break jak i całkiem puste.

> Już wyczerpałem temat

Ty to już jakiś czas temu ;p

> i nie zabieram głosu w tej sprawie.

wreszcie jakaś roztropna decyzja

v.

W dniu 2012-01-23 11:51, Cezary Tomczyk pisze:
> W dniu 2012-01-23 09:21, NKAB - pisze:
> [...]
>
> A ja dodam tylko tyle, że można sobie przetestować szybkość switch-a,
> if-a i ternary:
>
> http://jsperf.com/ternary-vs-if-vs-switch
>
> Ogólnie mi wyszło, że switch jest najwolniejszy :/

Tylko umyka taki maleńki niuansik, że switch potrafi załatwić bardziej 
zawiłą logikę - sprowadzanie go wyłącznie do roli zamiennika serii 
zagnieżdżonych warunków to akurat domena amatorów.
Owszem, to czyni takie zastosowanie _najczęstszym_.
Owszem, switch pozwala uczynić kod czytelniejszym.
Ale... do jasnej cholery, switch nie jest _tylko_ ekwiwalentem 
powyższego, i mimo, że takie zastosowanie wydać się może 
"najoczywistsze", to jednak wypada zdawać sobie sprawę, że działa zgoła 
odmiennie i tylko użycie break sprawia, iż zachowuje się w ten sposób.

switch(4){
  default:alert('ani raz, ani dwa ani trzy');
  case (alert('test raz'),1):alert('echo raz')
  case (alert('test dwa'),2):alert('echo dwa')
  case (alert('test trzy'),3):alert('echo trzy')
}


polecam sprawdzić różne wartości switch oraz przesuwanie linijki z 
default na różne pozycje i wtrącenie sobie jakiegoś/jakichś break tu czy 
tam - może niektórzy wreszcie skojarzą jak to działa ;)

v.

W dniu 2012-01-24 13:05, Vax pisze:
> W dniu 2012-01-23 11:51, Cezary Tomczyk pisze:
>> W dniu 2012-01-23 09:21, NKAB - pisze:
>> [...]
>>
>> A ja dodam tylko tyle, że można sobie przetestować szybkość switch-a,
>> if-a i ternary:
>>
>> http://jsperf.com/ternary-vs-if-vs-switch
>>
>> Ogólnie mi wyszło, że switch jest najwolniejszy :/
>
> Tylko umyka taki maleńki niuansik, że switch potrafi załatwić bardziej
> zawiłą logikę - sprowadzanie go wyłącznie do roli zamiennika serii
> zagnieżdżonych warunków to akurat domena amatorów.

No właśnie umknął jeszcze jeden maleńki niuansik, że ja podałem link do 
testu wydajnościowego, a nie pokazu "jak profesjonalnie zarządzać 
warunkami w JavaScripcie" ;-)

> Owszem, to czyni takie zastosowanie _najczęstszym_.
> Owszem, switch pozwala uczynić kod czytelniejszym.
> Ale... do jasnej cholery, switch nie jest _tylko_ ekwiwalentem
> powyższego, i mimo, że takie zastosowanie wydać się może
> "najoczywistsze", to jednak wypada zdawać sobie sprawę, że działa zgoła
> odmiennie i tylko użycie break sprawia, iż zachowuje się w ten sposób.
>
> switch(4){
> default:alert('ani raz, ani dwa ani trzy');
> case (alert('test raz'),1):alert('echo raz')
> case (alert('test dwa'),2):alert('echo dwa')
> case (alert('test trzy'),3):alert('echo trzy')
> }
>
>
> polecam sprawdzić różne wartości switch oraz przesuwanie linijki z
> default na różne pozycje i wtrącenie sobie jakiegoś/jakichś break tu czy
> tam - może niektórzy wreszcie skojarzą jak to działa ;)

Z mojego punktu widzenia to można schrzanić zarówno if-a, jak i 
switch-a. Nie ma złotej reguły na obie metody.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

W dniu 2012-01-24 13:26, Cezary Tomczyk pisze:

> No właśnie umknął jeszcze jeden maleńki niuansik, że ja podałem link do
> testu wydajnościowego,

dla _konkretnego_ przypadku - też niuansik taki, jeszcze ktoś inny 
wtrąca tu znienacka PHP - kolejny niuansik...
Akurat ta gałąź wątku traktuje, jak mi się wydaje, o tym, że switch *nie 
jest* wyłącznie zamiennikiem zagnieżdżonych warunków, a ów test 
wydajnościowy dziwnym trafem skupia się akurat na tym switcha aspekcie.

[...]

> Z mojego punktu widzenia to można schrzanić zarówno if-a, jak i
> switch-a. Nie ma złotej reguły na obie metody.

Coś nie bardzo po polsku chyba Ci wyszło ;)

A metodę to się dobiera indywidualnie do problemu, po uwzględnieniu i 
zbalansowaniu aspektów takich jak wydajność, czytelność, łatwość 
konserwacji kodu itp. - a kiedyś jeszcze istotna była tzw. "elegancja" ;)

v.

W dniu 2012-01-24 13:43, Vax pisze:
> W dniu 2012-01-24 13:26, Cezary Tomczyk pisze:
>
>> No właśnie umknął jeszcze jeden maleńki niuansik, że ja podałem link do
>> testu wydajnościowego,
>
> dla _konkretnego_ przypadku - też niuansik taki, jeszcze ktoś inny
> wtrąca tu znienacka PHP - kolejny niuansik...

Ekhm, to nie ja tworzyłem ten test. Wskazałem tylko link i pewien 
właśnie przypadek pokazujący wydajność poszczególnych metod. Wybór 
metody zależy od indywidualnych warunków, które na końcu posta elegancko 
zdefiniowałeś.

> Akurat ta gałąź wątku traktuje, jak mi się wydaje, o tym, że switch *nie
> jest* wyłącznie zamiennikiem zagnieżdżonych warunków, a ów test
> wydajnościowy dziwnym trafem skupia się akurat na tym switcha aspekcie.
>
> [...]
>
>> Z mojego punktu widzenia to można schrzanić zarówno if-a, jak i
>> switch-a. Nie ma złotej reguły na obie metody.
>
> Coś nie bardzo po polsku chyba Ci wyszło ;)

Ah, tam zaraz nie wyszło ;-)

> A metodę to się dobiera indywidualnie do problemu, po uwzględnieniu i
> zbalansowaniu aspektów takich jak wydajność, czytelność, łatwość
> konserwacji kodu itp. - a kiedyś jeszcze istotna była tzw. "elegancja" ;)

Chciałbym, by większość programistów tak myślała. Niestety, to 
mniejszość :-(

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

prof pisze:
> W dniu 2012-01-23 11:59, PawelS pisze:
> 
>> Bądź łaskaw zaszczycić mnie swoim pięknym kodem.
> 
> a ile chcesz mu zapłacić?
> 
>> Potomni będą mogli od Ciebie się uczyć ;)
> 
> Potomni już mogą, a Ty chcesz, żeby za Ciebie poprawiać.
> 
> case 'cokolwiek1':return $this->USERPERMISSIONS[...blabla1...];
> case 'cokolwiek2':return $this->USERPERMISSIONS[...blabla2...];
> case 'cokolwiek3':return $this->USERPERMISSIONS[...blabla3...];
> default:return $this->USERPERMISSIONS[...blabla...];

OK tylko, że z tym returnem to trochę pojechałeś,
może niezbyt czytelnie wyszedł ten [...inline_ciach...],
w założeniu funkcja/metoda ma zwrócić typ boolean,
w zależności od wartości jaka się znajdzie w tablicy,
a tutaj w tablicy USERPERMISSIONS[string_key]
mogą być zapisane różne wartości,
także Twój przykład kodu równie dobrze można zapisać:
return rand(); :P

> 
> ode mnie masz za free ;P
> 
> gdybyś jeszcze nie robił [...inline_ciach...] to jeszcze mogło by się 
> okazać, że cały ten switch jest zbędny.

W dniu 2012-01-24 15:25, PawelS pisze:

> OK tylko, że z tym returnem to trochę pojechałeś,
> może niezbyt czytelnie wyszedł ten [...inline_ciach...],
> w założeniu funkcja/metoda ma zwrócić typ boolean,

to trzeba było napisać, że musi być boolean (a potrafisz uzasadnić 
dlaczego?) gdyż sam dokonujesz testowania bliżej nieokreślonej wartości 
(bez przyrównywania do żadnej innej), zatem (być może o tym nie wiedząc 
;)) posiłkujesz się ekwiwalentami logicznymi innych typów.

> w zależności od wartości jaka się znajdzie w tablicy,
> a tutaj w tablicy USERPERMISSIONS[string_key]
> mogą być zapisane różne wartości,
> także Twój przykład kodu równie dobrze można zapisać:
> return rand(); :P

coś bzdury gadasz, gdyż poprzednio sam wkleiłeś:
if ($this->USERPERMISSIONS[...inline_ciach...])
co w zależności od spełnienia warunku zwraca potem true lub false.
Zatem true zwrócisz gdy if potraktuje 
$this->USERPERMISSIONS[...inline_ciach...] jako prawdę, i analogicznie 
dla fałszu.
Jakim cudem return ma zwracać random, a if nie?

To ode mnie, też gratis, dostaniesz:

return!!$this->USERPERMISSIONS[...inline_ciach...];

ok, masz "po ludzku":
return(bool)$this->USERPERMISSIONS[...inline_ciach...];

To teraz możesz szukać takiego $bzdet dla którego:

return (bool)$bzdet;

to coś innego niż:

$bzdet?true:false;

albo:

if($bdet){
	return true;
}else{
	return false;
};

Ja wiem, że kod ma być przejrzysty, ale przejrzyste to jest pytanie "czy 
pada deszcz" które zwraca "TAK" lub "NIE".
Nie jest bardziej przejrzyste: "jeżeli pada deszcz odpowiedz TAK w 
przeciwnym przypadku odpowiedz NIE".

Nie martw się, bo widziałem już: "jeżeli odpowiedź na pytanie (czy pada 
deszcz) brzmi TAK to odpowiedz TAK w przeciwnym wypadku odpowiedz NIE".
Czyli coś w stylu:

if($deszcz==true){
	return true;
}else{
	return false;
}

zamiast normalnego:

return $deszcz;
(z opcjonalnym rzutowaniem typu, gdy $deszcz nie jest boolowskie a na 
wyjściu _musi_ być boolean).

Ty plasujesz się gdzieś pośrodku ;p

Więc zapewne nie napiszesz
return $x>0;
tylko sklecisz jakiegoś if'a z dwoma returnami, choć $x>0 samo w sobie 
jest już boolowskie.

v.
PS. po raz kolejny uprzejmie informuję, że to _nie_ jest 
pl.comp.lang.php, którą też czasami podczytuję ;)

Vax pisze:
> W dniu 2012-01-24 15:25, PawelS pisze:
> 
>> OK tylko, że z tym returnem to trochę pojechałeś,
>> może niezbyt czytelnie wyszedł ten [...inline_ciach...],
>> w założeniu funkcja/metoda ma zwrócić typ boolean,
> 
> to trzeba było napisać, że musi być boolean (a potrafisz uzasadnić 
> dlaczego?) gdyż sam dokonujesz testowania bliżej nieokreślonej wartości 
> (bez przyrównywania do żadnej innej), zatem (być może o tym nie wiedząc 
> ;)) posiłkujesz się ekwiwalentami logicznymi innych typów.

wykonuję ściśle określone porównania,
które z pewnych powodów wyciąłem,

> 
>> w zależności od wartości jaka się znajdzie w tablicy,
>> a tutaj w tablicy USERPERMISSIONS[string_key]
>> mogą być zapisane różne wartości,
>> także Twój przykład kodu równie dobrze można zapisać:
>> return rand(); :P
> 
> coś bzdury gadasz, gdyż poprzednio sam wkleiłeś:
> if ($this->USERPERMISSIONS[...inline_ciach...])
> co w zależności od spełnienia warunku zwraca potem true lub false.
> Zatem true zwrócisz gdy if potraktuje 
> $this->USERPERMISSIONS[...inline_ciach...] jako prawdę, i analogicznie 
> dla fałszu.

nie zrozumiałeś chyba [...inline_ciach...],
to miało ukryć to i owo, a nie tylko element,
zapisany pod indeksem "...inline_ciach...",
bo tak to po trosze wygląda patrząc na powyższe,
jakbym usunął element wskazujący indeks (string) elementu,

> Jakim cudem return ma zwracać random, a if nie?

bardzo prostym logicznym warunkiem:
tu poniżej porównuję to pole z 1,
chociaż nie zawsze porównanie jest z 1:
if ($this->PROJECTROW['is_public']==1) {
   return true;
} else {
   return false;
}

tu poniżej sprawdzam nie pustość pola:
if (!empty($this->USERPERMISSIONS['log_time'])) {
   return true;
} else {
   return false;
}

a tu np: zdarza się jeszcze sprawdzać użytkownik jest adminem:
if (AuthRedmine::getInstance()->isAdmin()) {
/* USER IS ADMIN ($this->AUTHROW[admin]==1) ACCESS GRANTED */
   return true;
} else {
   return false;
}

teraz zapisz mi to swoim skrótem,
a potem wróć do tego kodu za pół roku,
ciekawe czy wlot zrozumiesz
co miałeś na myśli pół roku temu,

> 
> To ode mnie, też gratis, dostaniesz:
> 
> return!!$this->USERPERMISSIONS[...inline_ciach...];
> 
> ok, masz "po ludzku":
> return(bool)$this->USERPERMISSIONS[...inline_ciach...];
> 
> To teraz możesz szukać takiego $bzdet dla którego:
> 
> return (bool)$bzdet;
> 
> to coś innego niż:
> 
> $bzdet?true:false;
> 
> albo:
> 
> if($bdet){
>     return true;
> }else{
>     return false;
> };
> 
> Ja wiem, że kod ma być przejrzysty, ale przejrzyste to jest pytanie "czy 
> pada deszcz" które zwraca "TAK" lub "NIE".
> Nie jest bardziej przejrzyste: "jeżeli pada deszcz odpowiedz TAK w 
> przeciwnym przypadku odpowiedz NIE".
> 
> Nie martw się, bo widziałem już: "jeżeli odpowiedź na pytanie (czy pada 
> deszcz) brzmi TAK to odpowiedz TAK w przeciwnym wypadku odpowiedz NIE".
> Czyli coś w stylu:
> 
> if($deszcz==true){
>     return true;
> }else{
>     return false;
> }
> 
> zamiast normalnego:
> 
> return $deszcz;
> (z opcjonalnym rzutowaniem typu, gdy $deszcz nie jest boolowskie a na 
> wyjściu _musi_ być boolean).
> 
> Ty plasujesz się gdzieś pośrodku ;p
> 
> Więc zapewne nie napiszesz
> return $x>0;
> tylko sklecisz jakiegoś if'a z dwoma returnami, choć $x>0 samo w sobie 
> jest już boolowskie.
> 
> v.
> PS. po raz kolejny uprzejmie informuję, że to _nie_ jest 
> pl.comp.lang.php, którą też czasami podczytuję ;)
czy jesteś aż tak ograniczony,
że nie widzisz że kod w PHP miał pokazać ideę,
nie chciało mi się go przepisywać na JSa,
więc wkleiłem PHP, ale w sumie w JS też bym go podobnie zapisał,

W dniu 2012-01-24 22:28, PawelS pisze:

> wykonuję ściśle określone porównania,
> które z pewnych powodów wyciąłem,

no i? owe "ściśle określone" _porównania_ już zwracają bool.
Albo porównanie jest prawdziwe, albo jest fałszem.
Zatem:

return jakieś_porównanie;

zamiast

if(jakieś_porównanie){
  return true;
}else{
  return false;
}

bo to właśnie masło maślane i zamiast zwrócić wynik "czy 5 jest
większe od trzech?" (TAK/NIE) wykonujesz: "jeżeli prawdą jest, że pięć 
jest większe od trzech, odpowiedz TAK a jeśli NIE to odpowiedz NIE"

> nie zrozumiałeś chyba [...inline_ciach...],

nie zrozumiałeś chyba, że nawet jeśli ten niefortunny zapis jest 
porównaniem, to jego wynik JUŻ jest wartością logiczną, gotową do 
zwrócenia, po co ten zbędny bełkot "jeśli to prawda to prawda a jak nie 
to fałsz"? ;p

>> Jakim cudem return ma zwracać random, a if nie?
>
> bardzo prostym logicznym warunkiem:
> tu poniżej porównuję to pole z 1,
> chociaż nie zawsze porównanie jest z 1:
> if ($this->PROJECTROW['is_public']==1) {
> return true;
> } else {
> return false;
> }

i jakim to cudem:

return $this->PROJECTROW['is_public']==1;

ma zwracać wartość losową?
Zwróci dokładnie to samo, co Twój bełkot, tylko szybciej.

> tu poniżej sprawdzam nie pustość pola:
> if (!empty($this->USERPERMISSIONS['log_time'])) {
> return true;
> } else {
> return false;
> }

return !empty($this->USERPERMISSIONS['log_time'];

> a tu np: zdarza się jeszcze sprawdzać użytkownik jest adminem:
> if (AuthRedmine::getInstance()->isAdmin()) {
> /* USER IS ADMIN ($this->AUTHROW[admin]==1) ACCESS GRANTED */
> return true;
> } else {
> return false;
> }

straszne!

return AuthRedmine::getInstance()->isAdmin();

> teraz zapisz mi to swoim skrótem,

proszę, powyżej.

> a potem wróć do tego kodu za pół roku,
> ciekawe czy wlot zrozumiesz
> co miałeś na myśli pół roku temu,

Ty jakiś ociężały jesteś?

1. return $this->PROJECTROW['is_public']==1;
odpowiedz "czy klucz is_public jest równy jeden"

2. return !empty($this->USERPERMISSIONS['log_time'];
zwróć "nie-pustość" klucza log_time

3. return AuthRedmine::getInstance()->isAdmin();
przekaż odpowiednią wartość zwróconą przez daną metodę.

...zamiast dodatkowo bełkotać, że jeśli to co mam zwrócić (pewien 
warunek) jest prawdą, to zwracam (jakże egzotycznie) prawdę, a jeśli 
nieprawdą, to zwracam, uwaga, zaskoczenie... nieprawdę!

[ciach - bezsensownie zacytowany kawał postu]

> czy jesteś aż tak ograniczony,

nie, Ty jesteś ograniczony, mylisz grupy i nie wycinasz zbędnych cytatów.

> że nie widzisz że kod w PHP miał pokazać ideę,

czy jesteśtak ograniczony, żeby na grupie o JS nie potrafić pokazać idei 
w tymże języku?
Może mam Ci przekazać idee w assemblerze Z80?

> nie chciało mi się go przepisywać na JSa,

czyli okazałeś brak szacunku potencjalnym czytelnikom

> więc wkleiłem PHP, ale w sumie w JS też bym go podobnie zapisał,

Czyli zapisałbyś jak baran, który nie rozumie swego(?) kodu i powiela 
tylko jakieś "wzorce projektowe".

Sorry, ale sam się prosisz...

v.

W dniu 2012-01-24 23:37, Vax pisze:
[...]
> Może mam Ci przekazać idee w assemblerze Z80?
[...]

BTW nie byłoby tak źle :P

LD L, +2F
LD DE, +FFFF
LD BC, +FEFE
[... itd]

Ah, to były czasy... :D

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

Vax pisze:
> W dniu 2012-01-24 22:28, PawelS pisze:
> 
>> wykonuję ściśle określone porównania,
>> które z pewnych powodów wyciąłem,
> 
> no i? owe "ściśle określone" _porównania_ już zwracają bool.
> Albo porównanie jest prawdziwe, albo jest fałszem.
> Zatem:
> 
> return jakieś_porównanie;
> 
> zamiast
> 
> if(jakieś_porównanie){
>  return true;
> }else{
>  return false;
> }
> 
> bo to właśnie masło maślane i zamiast zwrócić wynik "czy 5 jest
> większe od trzech?" (TAK/NIE) wykonujesz: "jeżeli prawdą jest, że pięć 
> jest większe od trzech, odpowiedz TAK a jeśli NIE to odpowiedz NIE"
> 
>> nie zrozumiałeś chyba [...inline_ciach...],
> 
> nie zrozumiałeś chyba, że nawet jeśli ten niefortunny zapis jest 
> porównaniem, to jego wynik JUŻ jest wartością logiczną, gotową do 
> zwrócenia, po co ten zbędny bełkot "jeśli to prawda to prawda a jak nie 
> to fałsz"? ;p
> 
>>> Jakim cudem return ma zwracać random, a if nie?
>>
>> bardzo prostym logicznym warunkiem:
>> tu poniżej porównuję to pole z 1,
>> chociaż nie zawsze porównanie jest z 1:
>> if ($this->PROJECTROW['is_public']==1) {
>> return true;
>> } else {
>> return false;
>> }
> 
> i jakim to cudem:
> 
> return $this->PROJECTROW['is_public']==1;
> 
> ma zwracać wartość losową?
> Zwróci dokładnie to samo, co Twój bełkot, tylko szybciej.
> 
>> tu poniżej sprawdzam nie pustość pola:
>> if (!empty($this->USERPERMISSIONS['log_time'])) {
>> return true;
>> } else {
>> return false;
>> }
> 
> return !empty($this->USERPERMISSIONS['log_time'];
> 
>> a tu np: zdarza się jeszcze sprawdzać użytkownik jest adminem:
>> if (AuthRedmine::getInstance()->isAdmin()) {
>> /* USER IS ADMIN ($this->AUTHROW[admin]==1) ACCESS GRANTED */
>> return true;
>> } else {
>> return false;
>> }
> 
> straszne!
> 
> return AuthRedmine::getInstance()->isAdmin();
> 
>> teraz zapisz mi to swoim skrótem,
> 
> proszę, powyżej.
> 
>> a potem wróć do tego kodu za pół roku,
>> ciekawe czy wlot zrozumiesz
>> co miałeś na myśli pół roku temu,
> 
> Ty jakiś ociężały jesteś?
> 
> 1. return $this->PROJECTROW['is_public']==1;
> odpowiedz "czy klucz is_public jest równy jeden"
> 
> 2. return !empty($this->USERPERMISSIONS['log_time'];
> zwróć "nie-pustość" klucza log_time
> 
> 3. return AuthRedmine::getInstance()->isAdmin();
> przekaż odpowiednią wartość zwróconą przez daną metodę.
> 
> ...zamiast dodatkowo bełkotać, że jeśli to co mam zwrócić (pewien 
> warunek) jest prawdą, to zwracam (jakże egzotycznie) prawdę, a jeśli 
> nieprawdą, to zwracam, uwaga, zaskoczenie... nieprawdę!

Brawo, brawo, brawo,
genialne, bardzo genialne,
przez chwilę zastanawiałem się czemu tak właśnie nie zrobiłem
co wydaje się być logiczne,
po co zwracać true, jeśli sam warunek jest true,
zamiast zwrócić samego warunku, który by już zwrócił co trzeba.

Niestety za dużo ze swego kodu wyciąłem
przez co stał się on nieczytelny
i nie pokazał co tak naprawdę robię wykonuję,
zwłaszcza to return false było bardzo mylące:
W swej magicznej metodzie: checkpermissions()
zwracam true tylko w przypadku gdy zezwalam na wykonanie danego kodu,
w przeciwnym przypadku w zależności od różnych czynników
(błędne dane nie pozwalające określić uprawnienia,
dane pozwalające stwierdzić brak uprawnień do wykonania czynności
ewentualnie formularz z logowaniem jeśli wymagany jest użytkownik
inny niż anonimowy - każdy bez zalogowania)
wykonuję jedną z następujących czynności:
1:return AuthRedmine::getInstance()->NotFound(); // zwraca false
2:return AuthRedmine::getInstance()->Forbidden(); // zwraca false
3:if(AuthRedmine::getInstance()->loginRequired()&&AuthRedmine::getInstance()->isAnonymous()){
3:  /* AUTHROW['login_required']==1 */
3:  $applogin=new Login();
3:  $applogin->loginCall();
3:  return false; // zwraca false
3:}

równie dobrze mógłbym zapisać:
return $applogin->loginCall();
jedna linia mniej byłaby,

Teraz bardzo uprzejmie proszę was moi szanowni przedmówcy
podajcie swoje złote środki o ile to nie jest top secret
oraz o ile nic wam nie grozi za podzielenie się waszą
tajemniczą i przeogromną wiedzą.
Nie myślałem nad tym za długo, więc tak mi wyszedł
ten mój swego rodzaju model uprawnień,
może i trochę zagmatwany, ale szczerze wierzę w to
że zaraz mnie poprawicie i pokażecie
jak to porządnie/profesjonalnie zapisać.

> [ciach - bezsensownie zacytowany kawał postu]
> 
>> czy jesteś aż tak ograniczony,
> 
> nie, Ty jesteś ograniczony, mylisz grupy i nie wycinasz zbędnych cytatów.
> 
>> że nie widzisz że kod w PHP miał pokazać ideę,
> 
> czy jesteśtak ograniczony, żeby na grupie o JS nie potrafić pokazać idei 
> w tymże języku?
> Może mam Ci przekazać idee w assemblerze Z80?
> 
>> nie chciało mi się go przepisywać na JSa,
> 
> czyli okazałeś brak szacunku potencjalnym czytelnikom
> 
>> więc wkleiłem PHP, ale w sumie w JS też bym go podobnie zapisał,
> 
> Czyli zapisałbyś jak baran, który nie rozumie swego(?) kodu i powiela 
> tylko jakieś "wzorce projektowe".
> 
> Sorry, ale sam się prosisz...
> 
> v.

W dniu 2012-01-26 19:54, PawelS pisze:

[ciach - po co to _wszystko_ cytujesz?]

> Brawo, brawo, brawo,
> genialne, bardzo genialne,

samodzielne zrobienie kawy to dopiero by musiało wywrzeć na na Tobie 
wrażenie...
Powyższe było naturalne i logiczne, nie zaraz "genialne". No ok, Tobie 
się mogło takie wydać.

> przez chwilę zastanawiałem się czemu tak właśnie nie zrobiłem
> co wydaje się być logiczne,
> po co zwracać true, jeśli sam warunek jest true,
> zamiast zwrócić samego warunku, który by już zwrócił co trzeba.

prawda, że bezmyślne?

[kolejne wielkie ciach]

Resztę sobie podaruję, dlatego, że:
- to nie jest właściwa grupa, do dyskusji na _Twoim_ "modelem uprawnień" 
pisanym w _PHP_;
- znowu zacytowałeś _zbędny_ i _obszerny_ fragment poprzednich postów, 
do których się absolutnie nie odnosisz.

To, co można by Ci przekazać niefortunnie dociera dopiero po nazbyt 
dużej liczbie powtórzeń, albo wcale i całkiem prawdopodobne, że nie w 
formie, w jakieś zostało napisane, co czyni dalszą dyskusję z Tobą 
jałową i absolutnie "nieopłacalną".

v.

Vax pisze:
[...]
> To, co można by Ci przekazać niefortunnie dociera dopiero po nazbyt 
> dużej liczbie powtórzeń, albo wcale i całkiem prawdopodobne, że nie w 
> formie, w jakieś zostało napisane, co czyni dalszą dyskusję z Tobą 
> jałową i absolutnie "nieopłacalną".

wedle uznania,
thx

> 
> v.