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

Użyj WeakMap():

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

[...]

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

do góry

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

> Użyj WeakMap():
>
> https://www.nczonline.net/blog/2014/01/21/private-in
stance-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

do góry

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

do góry

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-in
stance-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.

do góry

W dniu 2015-10-05 o 09:33, n...@t...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

do góry

W dniu wtorek, 6 października 2015 17:39:39 UTC+2 użytkownik Marek napisał:
> W dniu 2015-10-05 o 09:33, n...@t...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.

do góry