W dniu 2015-09-27 o 18:46, Borys Pogoreło pisze:


> Teraz zgaduję - zapewne w prototypie ustawiana jest referencja na zmienną
> data, przez co jej wartość jest nadpisana w drugim wywołaniu testClass()
> (tu by się jednak przydała opinia kogoś, kto na JS zjadł sobie zęby).
> Zamiast takich kombinacji możesz zrobić getter getData() w obiekcie
> testClass lub po prostu zapisuj od razu do własności obiektu, czyli
> this.data = _data. Gdybyś wyrzucił definiowanie prototypu poza funkcję, to
> w ogóle by nie doszło do takiej sytuacji.

No i tu mam kilka zastrzeżeń.

1. Jeśli definiowanie prototypu wyrzucę poza funkcję to tracę dostęp do
zmiennych prywatnych. Przestają one istnieć.

2. Jeśli użyję this.zmienna, to staje się ona publiczną, a tego nie
chcę. Aż prosi się o katastrofę podczas dziedziczenia "klas" gdy klasa
potomna będzie używała tak samo nazwanej zmiennej.

3. Gettery / settery wykonały krok wstecz w kolejnych odsłonach JS.
Kiedyś istniała piękna właściwość __defineGetter__ / __defineSetter__
gdzie można było nazwać getter X, który ustawiał zmienną X. Obecnie
defineProperty musi nazywać się inaczej niż zmienna jaką ustawiamy. Robi
się to bardzo kłopotliwe w używaniu gdy każda zmienna inaczej musi
nazywać się lokalnie i na zewnątrz.

No i jestem w kropce... Czy nie da się tego naprawdę jakoś rozwiązać?

--
Pozdrawiam,
Marek

do góry

W dniu 2015-09-28 o 09:02, n...@t...net.pl pisze:


> Według spisu instrukcji piszą, że "prototype" daje możliwość
> zewnętrznego (zwracam uwagę na - zewnętrznego), a ja dodam sztucznego,
> dodawania właściwości do istniejącego bytu (funkcja/klasa).

Wiesz... jest znacznie gorzej bo dochodzą takie konstrukcje jak:

a.prototype=Object.create(b.prototype)
a.prototype.construtor=...

które nie wiadomo jak działają a służą do tworzenia dziedziczenia. Czyli
co? Zmieniam właściwość "prototyp" dla instancji "a"???? Jakaś bzdura z
tego powstaje. Zniesmacza mnie język, w którym trzeba uczyć się zaklęć
zamiast stosowania mózgu. A najgorsze w tym jest to, że nie ma
dokumentacji, która jasno mówiłaby "zrób tak lub siak" aby dziedziczenie
osiągnąć lub "ten język nie ma dziedziczenia". Tymczasem wprowadzają
jakieś prototypy nie wiadomo jak działające i każdy zgaduje do czego
służą. Nic się kupy nie trzyma. No dobra, wyraziłem swoją frustrację :-)
--
Pozdrawiam,
Marek

do góry

Dnia Mon, 28 Sep 2015 15:37:07 +0200, Marek napisał(a):

> No i tu mam kilka zastrzeżeń.
>
> 1. Jeśli definiowanie prototypu wyrzucę poza funkcję to tracę dostęp do
> zmiennych prywatnych. Przestają one istnieć.

I prawidłowo, nie do tego służy prototyp (jak nawet na to wskazuje jego
nazwa). Jeśli chcesz koniecznie zasymulować zmienne prywatne, których w JS
nie ma, to idź inną drogą (np. dość popularnego wzorca, który zakłada
zwrócenie obiektu "publicznego" przy inicjalizacji obiektu, który jedank
nadal ma dostęp do zmiennych z zakresu inicjalizacji).

> No i jestem w kropce... Czy nie da się tego naprawdę jakoś rozwiązać?

To jest własnie cały JS... wieczne "jakoś" ;)

ES6 ma chyba już coś, co wygląda trochę jak normalne klasy, ale to taki
półśrodek, a realnie użyć tego będzie mozna za kilka lat jak się
upowszechni.

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry

W dniu 9/28/2015 o 6:22 PM, Borys Pogoreło pisze:
[...]

> ES6 ma chyba już coś, co wygląda trochę jak normalne klasy, ale to taki
> półśrodek, a realnie użyć tego będzie mozna za kilka lat jak się
> upowszechni.

Rozwiązaniem na dziś może być:

* TypeScript - wsparcie do tego ma MS Visual Studio albo IntelliJ IDEA:
https://www.jetbrains.com/idea/help/typescript-suppo
rt.html. Wynikowy
kod JavaScript może nie jest idealny, ale działa ;-)

*
http://blog.jetbrains.com/webstorm/2015/05/ecmascrip
t-6-in-webstorm-transpiling/,
czyli IntelliJ IDEA i transpiling (nie wiem jak to po polsku napisać
:-)) w locie.

* ewentualnie Grunt task: https://www.npmjs.com/package/grunt-es6-transpiler

TypeScript próbowałem. Nieźle nadaje się do ogarnięcia wielkich
projektów, przyjemny refactoring, i parę innych rzeczy.

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

do góry

Dnia Mon, 28 Sep 2015 20:42:21 +0200, Cezary Tomczyk napisał(a):

> TypeScript próbowałem. Nieźle nadaje się do ogarnięcia wielkich
> projektów, przyjemny refactoring, i parę innych rzeczy.

To wiele mówi o języku, że powstają kolejne języki by zlikwidować problemy
tego pod spodem :) TypeScript, CoffeeScript, a nawet Dart...

I dzięki za hint z IDEA, ja się wciąż nie przekopałem przez więcej niż 1/3
opcji tego kombajnu...

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry

W dniu poniedziałek, 28 września 2015 15:46:46 UTC+2 użytkownik Marek napisał:
> W dniu 2015-09-28 o 09:02, n...@t...net.pl pisze:
>
>
> > Według spisu instrukcji piszą, że "prototype" daje możliwość
> > zewnętrznego (zwracam uwagę na - zewnętrznego), a ja dodam sztucznego,
> > dodawania właściwości do istniejącego bytu (funkcja/klasa).
>
> Wiesz... jest znacznie gorzej bo dochodzą takie konstrukcje jak:
>
> a.prototype=Object.create(b.prototype)
> a.prototype.construtor=...
>
> które nie wiadomo jak działają a służą do tworzenia dziedziczenia. Czyli
> co? Zmieniam właściwość "prototyp" dla instancji "a"???? Jakaś bzdura z
> tego powstaje. Zniesmacza mnie język, w którym trzeba uczyć się zaklęć
> zamiast stosowania mózgu. A najgorsze w tym jest to, że nie ma
> dokumentacji, która jasno mówiłaby "zrób tak lub siak" aby dziedziczenie
> osiągnąć lub "ten język nie ma dziedziczenia". Tymczasem wprowadzają
> jakieś prototypy nie wiadomo jak działające i każdy zgaduje do czego
> służą. Nic się kupy nie trzyma. No dobra, wyraziłem swoją frustrację :-)
> --
> Pozdrawiam,
> Marek

Najpierw musiałbyś powiedzieć do czego dążysz, co chcesz osiągnąć
bo twoje przykłady świadczą, że się chcesz nauczyć.

Musisz trzymać się konwencji języka.


Nie można napisać:

function f1()
{
this.a=null;
f1.prototype.b=null // dodajesz zmienną/właściwość - "b"
// (w tym miejscu takie dodawanie to trochę nie teges)
}

bo prawidłowo to jest tak:
function f1()
{
this.a=null;
this.b=null;
}

var o1=new f1(); // tworzysz obiekt "o1"
o1.a=1; // nadajesz wartości
o1.b=12;


f1.prtotyp.c=null; // teraz dodajesz nową zmienną/właściwość:
w1.c=123;


var o2=new f1(); // a teraz tworzysz nowy obiekt "o2"
o2.c=1234;

alert(o1.c+' i '+02.c);


Sztucznie można pokazać to tak, że funkcja/konstruktor/szablon do powielania
f1() ma teraz taką treść:

function f1()
{
this.a=null;
this.b=null;
this.c=null;
}


I co ci się kłóci.
Należy trzymać się konwencji języka i stosując tę konwencję kombinować
z kopiowaniem (dziedziczeniem).


Andrzej.

do góry

W dniu 2015-09-29 o 10:17, n...@t...net.pl pisze:

> I co ci się kłóci.

Już pokazuję co w "Twoim" podejściu się kłóci.
Mamy w klasie bazowej jak i pochodnej tak samo nazwaną zmienną (this.a):

function SuperClass(a,b)
{
this.a=a;
this.b=b;
}

SuperClass.prototype.parametry=function()
{
console.log("parametry", this.a, this.b);
};

function SubClass(a,b)
{
this.a=100;
SuperClass.call(this,a,b);
}

SubClass.prototype=Object.create(SuperClass.prototyp
e);

var obj=new SubClass(20,30);
obj.parametry();
console.log(obj.a);

Otrzymujemy:
parametry 20 30
20

Spodziewałbym się:
parametry 20 30
100

Wygląda na to, że zmienne używane w klasie bazowej są:
a) publiczne (czego nie chcę, ale mogę to jeszcze przełknąć)
b) nadpisywane zmiennymi z klasy potomnej!!!

Pisząc klasę potomną muszę zatem uważać aby nie powtórzyć nazwy zmiennej
z klasy bazowej. JS pozwala na tworzenie zmiennych gdziekolwiek w kodzie
więc w życiu nie dojdę jakie nazwy zmiennych są zastrzeżonymi. Mało tego
- jeśli w późniejszym czasie programista klasy bazowej dorzuci kolejną
zmienną to może rypnąć się cały projekt bo programiści klas potomnych
mogą już używać takiej nazwy zmiennej.

Nie wyobrażam sobie jak można nad tym zapanować w takim podejściu.

> Należy trzymać się konwencji języka i stosując tę konwencję kombinować
> z kopiowaniem (dziedziczeniem).

JS nie ma chyba nigdzie opisanej konwencji języka albo tych konwencji
jest tyle ilu programistów. Jeśli chcę się nauczyć C++, to kupuję
dowolny podręcznik i mam konwencję. W JS mogę co najmniej 3 "konwencje"
OOP przytoczyć i żadna z nich nie działa do końca.


--
Pozdrawiam,
Marek

do góry

W dniu czwartek, 1 października 2015 19:27:44 UTC+2 użytkownik Marek napisał:
> W dniu 2015-09-29 o 10:17, n...@t...net.pl pisze:
>
> > I co ci się kłóci.
>
> Już pokazuję co w "Twoim" podejściu się kłóci.
> Mamy w klasie bazowej jak i pochodnej tak samo nazwaną zmienną (this.a):
>
> function SuperClass(a,b)
> {
> this.a=a;
> this.b=b;
> }
>
> SuperClass.prototype.parametry=function()
> {
> console.log("parametry", this.a, this.b);
> };
>
> function SubClass(a,b)
> {
> this.a=100;
> SuperClass.call(this,a,b);
> }
>
> SubClass.prototype=Object.create(SuperClass.prototyp
e);
>
> var obj=new SubClass(20,30);
> obj.parametry();
> console.log(obj.a);
>
> Otrzymujemy:
> parametry 20 30
> 20
>
> Spodziewałbym się:
> parametry 20 30
> 100
>
> Wygląda na to, że zmienne używane w klasie bazowej są:
> a) publiczne (czego nie chcę, ale mogę to jeszcze przełknąć)
> b) nadpisywane zmiennymi z klasy potomnej!!!
>
> Pisząc klasę potomną muszę zatem uważać aby nie powtórzyć nazwy zmiennej
> z klasy bazowej. JS pozwala na tworzenie zmiennych gdziekolwiek w kodzie
> więc w życiu nie dojdę jakie nazwy zmiennych są zastrzeżonymi. Mało tego
> - jeśli w późniejszym czasie programista klasy bazowej dorzuci kolejną
> zmienną to może rypnąć się cały projekt bo programiści klas potomnych
> mogą już używać takiej nazwy zmiennej.
>
> Nie wyobrażam sobie jak można nad tym zapanować w takim podejściu.
>
> > Należy trzymać się konwencji języka i stosując tę konwencję kombinować
> > z kopiowaniem (dziedziczeniem).
>
> JS nie ma chyba nigdzie opisanej konwencji języka albo tych konwencji
> jest tyle ilu programistów. Jeśli chcę się nauczyć C++, to kupuję
> dowolny podręcznik i mam konwencję. W JS mogę co najmniej 3 "konwencje"
> OOP przytoczyć i żadna z nich nie działa do końca.
>
>
> --
> Pozdrawiam,
> Marek



Rzeczywiście muszę powtórzyć - niech wypowie się ktoś bardziej
wtajemniczony.

Ta twoja klasa to wcale nie klasa tylko funkcja, która ma udawać
klasę. W JS nie ma klas.


Zaś to "prototype" jest dla nas trochę abstrakcyjne i ja będąc Polakiem
zamienił bym na "addnewvar" czyli dodaj nową zmienną
i następnie var o1=new f1; to nic innego jak po polsku o1=copy f1();
czyli ten obiekt to dużym uproszczeniu kopia f1(), w której możesz
zmieniać do woli wartości zawartych tam zmiennych i są to wartości
zindywidualizowane.

Jeśli robisz szablon function f1(a,b)
to te "a", "b" (przesłane wartości)
są widoczne w każdej kopii (obiekcie).

Jestem programistą indywidualistą i unikam skomplikowanych
figur programistycznych bo nie są mi do niczego potrzebne,
to przecież tylko JS, który wykorzystuję wyłącznie do obsługi stron www,
dlatego cały czas pytam co chcesz uzyskać, bo na razie nie podałeś
konkretnego przykładu tylko błądzisz we mgle.

Andrzej.

do góry

W dniu 2015-10-02 o 09:31, n...@t...net.pl pisze:

> Ta twoja klasa to wcale nie klasa tylko funkcja, która ma udawać
> klasę. W JS nie ma klas.

Dlatego na początku ujmowałem słowo "klasa" w cudzysłów. Odpuściłem
sobie tych dwóch znaków i widzę, że mimo to powstało zamieszanie :-)

> Zaś to "prototype" jest dla nas trochę abstrakcyjne i ja będąc Polakiem
> zamienił bym na "addnewvar" czyli dodaj nową zmienną

Gdyby to takie proste było to bym nie pytał. Dodanie nowej "metody"
(wznawiam używanie cudzysłowu") do klasy za pomocą prototype i
bezpośrednio powoduje, że mimo tego samego kodu jedna będzie działać a
inna nie. Oto przykład:

function SuperClass()
{
var a=5;

this.showVar=function()
{
console.log(a);
}

SuperClass.prototype.showVar2=function()
{
console.log(a);
}
}

SuperClass.prototype.showVar3=function()
{
console.log(a);
}

var sc=new SuperClass();
sc.showVar(); //5
sc.showVar2(); //5 - ale przypisanie wartości do a ustawia ją we
wszystkich instancjach
sc.showVar3(); //error



> Jestem programistą indywidualistą i unikam skomplikowanych
> figur programistycznych bo nie są mi do niczego potrzebne,
> to przecież tylko JS, który wykorzystuję wyłącznie do obsługi stron www,
> dlatego cały czas pytam co chcesz uzyskać, bo na razie nie podałeś
> konkretnego przykładu tylko błądzisz we mgle.

Konkretny przykład jest bardzo złożony więc uznałem, że nie ma sensu
tego przytaczać. Wyjaśnię, że chodzi o interaktywną współpracę SVG ze
stroną WWW (edytor grafiki na stronie WWW). Kod liczy sobie setki linii,
wykorzystywany jest Ajax, współpraca z bazą danych oraz customizowane
zdarzenia do komunikowania się warstw aplikacji między sobą - coś na
wzór programowania dla Windows. Gdybym to przytoczył to zapewne ani
jednej odpowiedzi bym nie uzyskał.

Wyłuskałem konkretny problem z jakim się spotkałem (variable scope a w
nim m.in. dziwny "typ zmiennych" współdzielonych między instancjami, nie
opisany w dokumentacji JS) i nie uważam, że jest on błądzeniem we mgle.


--
Pozdrawiam,
Marek

do góry

W dniu piątek, 2 października 2015 12:02:30 UTC+2 użytkownik Marek napisał:
> W dniu 2015-10-02 o 09:31, n...@t...net.pl pisze:

> function SuperClass()
> {
> var a=5;
>
> this.showVar=function()
> {
> console.log(a);
> }
>
> // SuperClass.prototype.showVar2=function() // to jest ewidentny błąd
napisz tak:
this.showVar2=function()
> {
> console.log(a);
> }
> }
>

a to już właściwe miejsce na dodawanie zmiennej/właściwości/metody:

> SuperClass.prototype.showVar3=function()
> {
> console.log(a);
> }
>



Ja sprawdzam dane tak:


function f1(a,b)
{

this.a=a;
this.b=b;
console.log("1. a=",a," b=",b);

this.c=function(a1)
{
a=a1;
console.log("2. a1=",a);
return a;
}

}

var o1=new f1(11,22)
zm1=o1.c(33);

console.log("3. ",o1.a," ",zm1);

i widzę, że wartości "a" są inne w szablonie i inne w metodzie
i są zindywidualizowane pomimo tej samej nazwy.

Andrzej.

do góry