🚀 go-pugleaf

Dnia Sun, 20 Sep 2015 11:57:51 +0200, Marek napisał(a):

> błędy które programiście nie ujawnią się a użytkownikowi tak, bo wykonał 
> np. nieco odmienną akcję niż testerzy i ta sama funkcja raz zadziałała, 
> raz nie. Wydaje mi się iż musi istnieć jakaś inna składnia wywołań metod 
> prywatnych aby uniknąć takich problemów. Macie pomysły?

Mieszasz w zakresach widoczności funkcji. Zrób sobie na początku funkcji
test2(): var that = this; i już masz dostęp do "this" pod nową nazwą w
funkcjach zagnieżdżonych. Często znajdziesz taką konstrukcję w bibliotekach
JS.

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

W dniu 2015-09-20 o 18:05, Borys Pogoreło pisze:

> Mieszasz w zakresach widoczności funkcji. Zrób sobie na początku funkcji
> test2(): var that = this; i już masz dostęp do "this" pod nową nazwą w
> funkcjach zagnieżdżonych. Często znajdziesz taką konstrukcję w bibliotekach
> JS.

To nie zadziała. Rozwiązanie jakie przytaczasz jest raczej związane z 
nie-strict-mode. Problem w tym, że this = null w metodzie test2
Co ciekawe - w "klasie" test() operator this nie jest nullem.

Przynajmniej pod Edge to obserwuję.

-- 
Pozdrawiam,
Marek

W ogóle jest coś nie tak:

function testClass(_data)
	{
	var data=_data;
	
	testClass.prototype.read=function()
		{
		console.log("read",data);
		};
	}
	
aaa=new testClass(10);
aaa.read();
bbb=new testClass(20);
aaa.read();

daje wynik
10
20

Wygląda na to, że zmienna data staje się globalną z punktu widzenia 
testClass!! O co tu chodzi? Albo mnie coś przyćmiło, albo coś porządnie 
szwankuje w strict mode.

-- 
Pozdrawiam,
Marek

Dnia Sun, 20 Sep 2015 18:27:54 +0200, Marek napisał(a):

>> Mieszasz w zakresach widoczności funkcji. Zrób sobie na początku funkcji
>> test2(): var that = this; i już masz dostęp do "this" pod nową nazwą w
>> funkcjach zagnieżdżonych. Często znajdziesz taką konstrukcję w bibliotekach
>> JS.
> 
> To nie zadziała. Rozwiązanie jakie przytaczasz jest raczej związane z 
> nie-strict-mode. Problem w tym, że this = null w metodzie test2
> Co ciekawe - w "klasie" test() operator this nie jest nullem.

SOA#1

> Przynajmniej pod Edge to obserwuję.

Weź wyłącz ten badziew, same problemy z tym Edge.

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

Dnia Sun, 20 Sep 2015 18:48:12 +0200, Marek napisał(a):

> Wygląda na to, że zmienna data staje się globalną z punktu widzenia 
> testClass!! O co tu chodzi? Albo mnie coś przyćmiło, albo coś porządnie 
> szwankuje w strict mode.

Nic się nie staje globalne. Modyfikujesz prototyp, ale wywołanie i tak
operuje na instancji obiektu, która ma zmienną lokalną.

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

W dniu 2015-09-20 o 21:55, Borys Pogoreło pisze:

> Nic się nie staje globalne. Modyfikujesz prototyp, ale wywołanie i tak
> operuje na instancji obiektu, która ma zmienną lokalną.

Czy nie zauważyłeś, że instancja bbb zmodyfikowała zmienną data w 
instancji aaa? Zmienna data nie jest w tym przypadku lokalną bo 
przyjmuje wartość wspólną dla wszystkich instancji - zachowuje się 
globalnie.

Nie rozumiem zatem dlaczego jedna instancja widzi wartości zmiennych 
(prywatnych) drugiej instancji? Jak zatem spowodować aby poszczególne 
instancje nie zakłócały siebie nawzajem?

Metodą prób i błędów odkryłem, że drobna modyfikacja deklaracji funkcji:

function testClass(_data)
     {
     var data=_data;

     this.read=function()
         {
         console.log("read",data);
         };
     }

aaa=new testClass(10);
aaa.read();
bbb=new testClass(20);
aaa.read();

powoduje, że teraz odczyt będzie zupełnie inny:
10
10

Czyli instancja bbb nie zmodyfikowała zmiennej data w instancji aaa. 
Dlaczego? Zmienna jest identycznie przecież zadeklarowana. Dlaczego 
sposób zadeklarowania funkcji czytającej wpływa na zakres widoczności 
zmiennej?


-- 
Pozdrawiam,
Marek

P.S.
Rozpocznę nowy wątek. Nieco inaczej sformułuję pytanie w nim. Zależy mi 
na Twoim komentarzu.

Dnia Mon, 21 Sep 2015 11:43:23 +0200, Marek napisał(a):

> W dniu 2015-09-20 o 21:55, Borys Pogoreło pisze:
> 
>> Nic się nie staje globalne. Modyfikujesz prototyp, ale wywołanie i tak
>> operuje na instancji obiektu, która ma zmienną lokalną.
> 
> Czy nie zauważyłeś, że instancja bbb zmodyfikowała zmienną data w 
> instancji aaa? Zmienna data nie jest w tym przypadku lokalną bo 
> przyjmuje wartość wspólną dla wszystkich instancji - zachowuje się 
> globalnie.

Tak, teraz widzę. Ale ogólnie to strasznie naciągnąłeś możliwości języka i
nic dziwnego, że Ci cuda wychodzą :) Na pewno przez takie zdefiniowanie
prototypu powodujesz, że jego zakres widoczności sięga do granic funkcji i
przez to zmienna "data" jest widoczna, co nie znaczy że powinieneś do niej
sięgać. Z kolei modyfikacja prototypu jest współdzielona między obiektami
(choć tu jest parę zastrzeżeń).

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.

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

W dniu poniedziałek, 21 września 2015 11:43:25 UTC+2 użytkownik Marek napisał:
> W dniu 2015-09-20 o 21:55, Borys Pogoreło pisze:
> 
> > Nic się nie staje globalne. Modyfikujesz prototyp, ale wywołanie i tak
> > operuje na instancji obiektu, która ma zmienną lokalną.
> 
> Czy nie zauważyłeś, że instancja bbb zmodyfikowała zmienną data w 
> instancji aaa? Zmienna data nie jest w tym przypadku lokalną bo 
> przyjmuje wartość wspólną dla wszystkich instancji - zachowuje się 
> globalnie.
> 
> Nie rozumiem zatem dlaczego jedna instancja widzi wartości zmiennych 
> (prywatnych) drugiej instancji? Jak zatem spowodować aby poszczególne 
> instancje nie zakłócały siebie nawzajem?
> 
> Metodą prób i błędów odkryłem, że drobna modyfikacja deklaracji funkcji:
> 
> function testClass(_data)
>      {
>      var data=_data;
> 
>      this.read=function()
>          {
>          console.log("read",data);
>          };
>      }
> 
> aaa=new testClass(10);
> aaa.read();
> bbb=new testClass(20);
> aaa.read();
> 
> powoduje, że teraz odczyt będzie zupełnie inny:
> 10
> 10
> 
> Czyli instancja bbb nie zmodyfikowała zmiennej data w instancji aaa. 
> Dlaczego? Zmienna jest identycznie przecież zadeklarowana. Dlaczego 
> sposób zadeklarowania funkcji czytającej wpływa na zakres widoczności 
> zmiennej?
> 
> 
> -- 
> Pozdrawiam,
> Marek


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).

U ciebie jest to wewnątrz czyli nie za bardzo dobrze.

Skoro zewnętrznego to ta zmienna/właściwość  jest/musi  być już publiczna.



Ale rzeczywiście niech wypowie się ktoś bardziej wtajemniczony.




Andrzej.

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

W dniu 2015-09-28 o 09:02, nkab@toya.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

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

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-support.html. Wynikowy 
kod JavaScript może nie jest idealny, ale działa ;-)

* 
http://blog.jetbrains.com/webstorm/2015/05/ecmascript-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/

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

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, nkab@toya.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.

W dniu 2015-09-29 o 10:17, nkab@toya.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.prototype);

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

W dniu czwartek, 1 października 2015 19:27:44 UTC+2 użytkownik Marek napisał:
> W dniu 2015-09-29 o 10:17, nkab@toya.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.prototype);
> 
> 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.

W dniu 2015-10-02 o 09:31, nkab@toya.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

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, nkab@toya.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.

W dniu 10/1/2015 o 7:27 PM, Marek pisze:
[...]

> 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.prototype);
>
> 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ąć)

Użyj WeakMap():

https://www.nczonline.net/blog/2014/01/21/private-instance-members-with-weakmaps-in-javascript/

[...]

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

W dniu 2015-10-03 o 11:18, Cezary Tomczyk pisze:

> Użyj WeakMap():
>
> https://www.nczonline.net/blog/2014/01/21/private-instance-members-with-weakmaps-in-javascript/

Super! Dzięki! :-)

Najbardziej przydatna z tego informacja to użycie prototypu do "metody" 
w "klasie" zamiast do "klasy". Po drugie zamiast WeakMap można użyć 
bezpośrednich deklaracji zmiennych prywatnych var costam; To bardzo 
dobry trop :-) Dzięki raz jeszcze.


-- 
Pozdrawiam,
Marek

Hej,

Zerknij na rozwiązanie jakie Cezary zaproponował. Wykorzystam sztuczkę w 
stosowaniu prototypów wewnątrz "klasy" ale dotyczących jej 
"konstruktora". Proste i rozwiązuje problem. :-)

W dniu sobota, 3 października 2015 12:17:43 UTC+2 użytkownik Marek napisał:
> W dniu 2015-10-03 o 11:18, Cezary Tomczyk pisze:
> 
> > Użyj WeakMap():
> >
> > https://www.nczonline.net/blog/2014/01/21/private-instance-members-with-weakmaps-in-javascript/
> 
> Super! Dzięki! :-)
> 
> Najbardziej przydatna z tego informacja to użycie prototypu do "metody" 
> w "klasie" zamiast do "klasy". Po drugie zamiast WeakMap można użyć 
> bezpośrednich deklaracji zmiennych prywatnych var costam; To bardzo 
> dobry trop :-) Dzięki raz jeszcze.
> 
> 
> -- 
> Pozdrawiam,
> Marek

Czyli, że brakowało ci informacji o zasięgu zmiennych
w funkcjach:


a=111;                 // globalna (publiczna) bo na zewnatrz funkcji
                       // (ta sama chierarchia dot. funkcji zagnieżdżonych)

function f1()
{
 var a=222;            // lokalna bo ma "var"
// a=333;              // globalna

 console.log("1. a=",a);   // wyświetli - 222



 function f2()
 {
  var a=444;          // lokalna
  a=555;              // globalna

  console.log("1. a=",a);   // wyświetli - 444

 }
 f2();



}

console.log("2. a=",a);   // przy aktywnym var a=... wyświetli - 111 (czyli zewnętrzną),
                          // przy nie aktywnych var a=... wyświetli - 555





A ja myślałem, że chodzi ci o zindywidualizowanie zmiennych globalnych
wewnątrz funkcji/metod, co uzyskiwałem przekazując jako parametr do funkcji:

a=111;
function f1()
{
 a=222;
 console.log("1. a=",a);    // 222

 function f2(a)
 { 
  a=333;
  console.log("2. a=",a);   // 333
 }
 f2();
}

console.log("3. a=",a);    // 222



Czyli f1() obrabia globalną "a" a f2() dostaje to obrobione w f1() "a"
i następnie przetwarza dalej to globalne ale już zindywidualizowane "a".


Andrzej.

W dniu 2015-10-05 o 09:33, nkab@toya.net.pl pisze:

>
> Czyli, że brakowało ci informacji o zasięgu zmiennych
> w funkcjach:

Raczej o triku, który pozwoli obejść problem powstawania "dziwnych" 
zmiennych współdzielonych między instancjami a jednocześnie trzymania 
ich jako prywatne "klas". Nie potrafiłem pogodzić jednego z drugim.

>
> a=111;                 // globalna (publiczna) bo na zewnatrz funkcji
>                         // (ta sama chierarchia dot. funkcji zagnieżdżonych)
>
> function f1()
> {
>   var a=222;            // lokalna bo ma "var"
> // a=333;              // globalna
 > (...)

To akurat podstawy JS - zupełnie nie o to mi chodziło.

>
> A ja myślałem, że chodzi ci o zindywidualizowanie zmiennych globalnych
> wewnątrz funkcji/metod, co uzyskiwałem przekazując jako parametr do funkcji:

Nie, może niefortunnie nazwałem "globalnym" ten dziwny zasięg zmiennych. 
Ale nie znam innego słowa bo w instancjach "klas" zachowywały się one 
jak globalne choć w "roocie" aplikacji nie były one widoczne - czyli z 
tego punktu widzenia jako nie-globalne.

-- 
Pozdrawiam,
Marek

W dniu wtorek, 6 października 2015 17:39:39 UTC+2 użytkownik Marek napisał:
> W dniu 2015-10-05 o 09:33, nkab@toya.net.pl pisze:
> 
> >
> > Czyli, że brakowało ci informacji o zasięgu zmiennych
> > w funkcjach:
> 
> Raczej o triku, który pozwoli obejść problem powstawania "dziwnych" 
> zmiennych współdzielonych między instancjami a jednocześnie trzymania 
> ich jako prywatne "klas". Nie potrafiłem pogodzić jednego z drugim.
> 
> >
> > a=111;                 // globalna (publiczna) bo na zewnatrz funkcji
> >                         // (ta sama chierarchia dot. funkcji zagnieżdżonych)
> >
> > function f1()
> > {
> >   var a=222;            // lokalna bo ma "var"
> > // a=333;              // globalna
>  > (...)
> 
> To akurat podstawy JS - zupełnie nie o to mi chodziło.
> 
> >
> > A ja myślałem, że chodzi ci o zindywidualizowanie zmiennych globalnych
> > wewnątrz funkcji/metod, co uzyskiwałem przekazując jako parametr do funkcji:
> 
> Nie, może niefortunnie nazwałem "globalnym" ten dziwny zasięg zmiennych. 
> Ale nie znam innego słowa bo w instancjach "klas" zachowywały się one 
> jak globalne choć w "roocie" aplikacji nie były one widoczne - czyli z 
> tego punktu widzenia jako nie-globalne.
> 
> -- 
> Pozdrawiam,
> Marek

Osobiście nie zajmuję się rzeczami, na które nie mam żadnego wpływu.
Interesuje mnie tylko co daje mi mój kod.

Andrzej.