[rozdajozadarmo]

Używacie getterów i setterów w #es6 ? Jeśli tak to jakiej używacie konwencji nazwenictwa? Poprzedzacie pole prefiksem: _?

np.:

const obj = {
    get prop() {
        return this._prop;
    },
    set prop(val) {
        this._prop = val + 1;
    }
};

#webdev #js #programowanie
pozwolę sobie zawołać @rezoner

[G.....n]

@rozdajozadarmo: Tak i tak.

[suawus]

Stosowanie _ w przypadku "prywatnych" pól jest powszechnie przyjętą praktyką, mam nadzieję że wszyscy do tego dojrzeją zamiast eknapsulować zmienne w anonimowych funkcjach...bo to tylko zaciemnia kod.

Polecam guide https://github.com/airbnb/javascript :)

[q.....u]

@rozdajozadarmo @suawus: nie używam, zgadzam się z airbnb (i to nie tylko jeśli chodzi o js)

Do not use JavaScript getters/setters as they cause unexpected side effects and are harder to test, maintain, and reason about. Instead, if you do make accessor functions, use getVal() and setVal('hello').

[G.....n]

Do not use JavaScript getters/setters as they cause unexpected side effects and are harder to test, maintain, and reason about. Instead, if you do make accessor functions, use getVal() and setVal('hello').

@qwertyu: Bo?

[rezoner]

@rozdajozadarmo: Tak samo jak @Ginden

Przeważnie kiedy coś ma wypluć prostą wartość, która składa się z wielu czynników

np:

get outerWidth() { return this.padding.left + this.width + this.padding.right; }

albo dla wrapperów:

get width() { return this.canvas.width; }

albo dla maszyny stanów:

set state(state) {

if(this.state) this.state.leave();

this._state = state;

this.state.enter();

}

Na pewno moje settery są bardzo krótkie i robią tylko proste rzeczy, żeby nie wpaść w pułapkę magicznie działającego

[kowad]

@suawus: przecież w przytoczonym przez Ciebie przewodniku jest dokładnie odwrotnie, zalecają nie używać podkreśleń:

Do not use trailing or leading underscores

https://github.com/airbnb/javascript#naming--leading-underscore

[suawus]

@kowad właśnie widzę... dałbym głowę że wcześniejsze wersje mówiły coś innego. W takim razie polecam stosować airbnb z umiarem, wedle rozsądku.

Ha, sie wstrzeliłem.. 3 dni temu to zmienili: https://github.com/airbnb/javascript/commit/92a66ccc7caeaf935653b5e9fed6d02f90ce6805

[suawus]

@rezoner @Ginden: wydaje mi się, że AirBnb odradza stosowanie akcesorów w postaci metod property(val) (tak jak ma to miejsce bodajze w jquery). Osobiście używam geterów takich jak @rezoner, stanowią bardzo fajną abstrakcje, a dla użytkownika końcowego są całkowicie transparentne.

[rozdajozadarmo]

@Ginden, @qwertyu, @rezoner
Dzięki.

@suawus:

Stosowanie _ w przypadku "prywatnych" pól jest powszechnie przyjętą praktyką, mam nadzieję że wszyscy do tego dojrzeją zamiast eknapsulować zmienne w anonimowych funkcjach...bo to tylko zaciemnia kod.

Nigdy nie byłem fanem tego podejścia, ale rzeczywiście masz racje, że każdy kawałek tzw 'boilerplate code' zaciemnia kod. A jak ktoś chce zepsuć, to i tak zepsuje bez względu na to czy zmienne są prawdziwie prywatne czy

[magic96]

@suawus: no trochę ten twój guide nie zgadza się z reprezentowaną przez Ciebie opinią ( ͡° ͜ʖ ͡°) https://github.com/airbnb/javascript#naming--leading-underscore

[suawus]

@magic96: Tak jak pisałem powyżej, zmienili to 3 dni temu https://github.com/airbnb/javascript/commit/92a66ccc7caeaf935653b5e9fed6d02f90ce6805

[magic96]

@suawus: ale w JS nie ma jawnej hermetyzacji… Poprzedzanie pól prywatnych underscorem to tylko kwestia umowna, po co takie coś stosować, skoro i tak możliwe jest przedostanie się do niej spoza obiektu? Moim zdaniem bardziej to zaciemnia kod, niż zastosowanie protezy hermetyzacji, jaką mogą być WeakMapy. W ES6 domknięcia to niekoniecznie dobry pomysł, bo samo IIFE jest zaliczane jako antywzorzec.

[suawus]

@magic69:

po co takie coś stosować, skoro i tak możliwe jest przedostanie się do niej spoza obiektu

Źeby wskazać użytkownikowi że nie powinien z tej zmiennej korzystać. Oczywiście jeżeli zdecyduje się do nich dobrać to nic go przed tym nie powstrzyma, ale programista został jednoznacznie poinformowany że nie powinien tego robić. Tzw. "privacy by convention"

Moim zdaniem stosowanie do tego celu WeakMap zaciemniają kod równie mocno co IIFE: zamiast wygodnego operatora

[rozdajozadarmo]

samo IIFE jest zaliczane jako antywzorzec.

@magic96:
Mogę prosić coś więcej na ten temat? Z chęcią poczytam.

[magic96]

@rozdajozadarmo: http://exploringjs.com/es6/ch_first-steps.html#_from-iifes-to-blocks

[rozdajozadarmo]

@magic96: OK, zrozumiałem twoją wypowiedź ogólnie: że IIFE są uważane jako antywzorzec, a ty miałeś na myśli, że są uważane za antywzorzec w tym konkretnym kontekście, tzn jako konstrukcja służąca do tworzenia kontekstu.

[magic96]

@rozdajozadarmo: eee co? xD Napisałem, że iife aka dotknięcia są antywzorcem w ES6 :)