🚀 go-pugleaf

Zadanie rozwiazalam :) Jednak przespanie sie z problemem czyni cuda.
Przede wszystkim popelnilam czeski blad, dwa razy mialam zdefiniowana
klase Pochodna, wiec blad, ze metoda nie jest funkcja byl jak
najbardziej na miejscu :)

Znalazlam tez dwa sposoby na dziedziczenie:
- prototypowanie, gdzie obiektKlasyPochodnej instanceof KlasaBazowa
zwraca true;
- wykorzystanie inheritFrom - co prawda mam dostep do wszystkich metod
KlasyBazowej, ale instanceof zwraca mi false...

Za wszelkie komentarze zwiazane z obiektowoscia w js bede nieustajaco
wdzieczna :)

On 12 Lip, 12:00, mmiarecka <mmiare...@gmail.com> wrote:
> Za wszelkie komentarze zwiazane z obiektowoscia w js bede nieustajaco
> wdzieczna :)

Po pierwsze, w JS nie ma czegoś takiego jak "klasa". Mechnizmem
zapewniającym dziedziczenie są tutaj prototypy. Słowo "klasa" należy
brać w cudzysłów i rozumieć przez nie "zbiór obiektów o wspólnym
prototypie".

Po drugie, dziedziczenie realizuje się ustawiając prototyp
konstruktora obiektu pochodnego na instancję bazowego.

function Bazowa() {
// ...
}

function Pochodna() {
// ...
}
Pochodna.prototype = new Bazowa(); // tutaj :)

Po trzecie, publiczne funkcje obiektu, które nie potrzebują dostępu do
zmiennych w zasięgu konstruktora dodaje się do prototypu:

Pochodna.prototype.getName = function () {
// ...
}

w przeciwnym wypadku każdy obiekt ma swoją osobną kopię tej funkcji,
marnując pamięć.

Operator instanceof działa tylko na obiektach mających właściwy
łańcuch prototypów. Wywoływanie JakisKonstruktor.call(this) takiego
łańcucha nie buduje.

Po czwarte, nie ma w języku czegoś takiego jak inheritFrom.
Najwyraźniej korzystasz z jakiejś biblioteki.

Po piąte, podany przez Ciebie kod nie ma prawa nawet się uruchomić
(błędy składniowe). :)

Po szóste:

function Pochodna() {
  function Pochodna() {
  // ...
  }
}

Wewnętrzna funkcja Pochodna jest widoczna tylko w zasięgu nadrzędnej
funkcji o tej samej nazwie, co za tym idzie, nie byłaby w ogóle
używana, nawet, jeśli poprawiłabyś czysto formalne błędy składniowe.

--
marcoos.com

On 12 Lip, 19:43, marcoos <marek.step...@gmail.com> wrote:
[...]
> Po trzecie, publiczne funkcje obiektu, które nie potrzebują dostępu do
> zmiennych w zasięgu konstruktora dodaje się do prototypu:
> w przeciwnym wypadku każdy obiekt ma swoją osobną kopię tej funkcji,
> marnując pamięć.

To bardzo cenna uwaga, dziekuje.

> Po czwarte, nie ma w języku czegoś takiego jak inheritFrom.
> Najwyraźniej korzystasz z jakiejś biblioteki.

I tu mnie zastrzeliles... Takie rozwiazanie podpowiedzial mi
eclipse... nie importuje zadnej biblioteki... No nic bede musiala
poszukac.

> Wewnętrzna funkcja Pochodna jest widoczna tylko w zasięgu nadrzędnej
> funkcji o tej samej nazwie, co za tym idzie, nie byłaby w ogóle
> używana, nawet, jeśli poprawiłabyś czysto formalne błędy składniowe.

No wlasnie i tu pojawia sie problem. Takie rozwiazanie, jak
umieszczanie zmiennych prywatnych/protected i metod prywatnych/
protected znalazlam w necie: http://www.crockford.com/javascript/private.html
Jednak mimo najszczerszych checi chyba jednak nie rozumiem o co
biega... chyba ze ja zle rozumiem slowo 'constructor'.

To jak po ludzku zaimplementowac prywatne i protected zmienne i
metody?

Jeszcze raz dziekuje za cenne wskazowki.

On 15 Lip, 10:43, mmiarecka <mmiare...@gmail.com> wrote:
> To jak po ludzku zaimplementowac prywatne i protected zmienne i
> metody?

Tak naprawdę należy zapomnieć o próbowaniu przenoszenia pojęć Javy do
JS - jest to podejście dość sztuczne i nieco na siłę - i pamiętać
tylko, że zmienne są widoczne tylko w tym zasięgu, w którym zostały
zadeklarowane i w zasięgach potomnych. JS jest językiem totalnie
odmiennym od Javy, jedyne co ma wspólnego, to podobna składnia
odziedziczona po C, ale paradygmaty są zupełnie inne. Poniżej przykład
takiego "na siłę" podejścia...

Jedynym sposobem hermetyzacji w JS są closures, czyli zasięgi funkcji,
za pomocą których można symulować (nie do końca) zachowanie języków w
rodzaju Javy.

var MojeCos = (function () {
  var a; // cos w rodzaju "private static"

  function MojeCos(a1, b, c) { // a1, b, c - argumenty konstruktora
(jednoczesnie zmienne lokalne zasięgu MojeCos)
    var d = 7; // zmienna lokalna zasięgu MojeCos

    this.b = b; // publiczne b
    a = a1;  // zmiana "prywatnego statycznego" a

    this.doSth = function() { // publiczna metoda zdefiniowana w
konstruktorze, Crockford nazywa to "priviledged"
       alert(a1 + ", " + b + ", " + c + ", " + d); // ma dostęp do a1,
b, c i d dzięki closure
    }

  }

  MojeCos.x = 8; // cos jak "public static"

  MojeCos.prototype.doSthElse() { // publiczna metoda prototypu
    alert(a); // ma dostep do "private static"
    alert(this.b); // ma dostep do publicznych
    // alert(c) - nie zadziala, nie ma dostepu, c jest w innym zasiegu
  };

  return MojeCos;
}());

var mc = new MojeCos();
mc.doSth();
mc.doSthElse();
alert(mc.b);
alert(MojeCos.x);

Kod z głowy, nie testowany - jeśli się gdzieś nie pomyliłem, to
powinien działać. :)

--
marcoos.com

Użytkownik "marcoos" <marek.stepien@gmail.com> napisał w wiadomości 
news:5be0104f-8a8c-4001-8154-d8345db1e0e8@h18g2000yqj.googlegroups.com...
> Jedynym sposobem hermetyzacji w JS są closures, czyli zasięgi funkcji,

Jesteś absolutnie pewnym ? :) 

On 12 Lip, 19:43, marcoos <marek.step...@gmail.com> wrote:
[...]
> Po czwarte, nie ma w języku czegoś takiego jak inheritFrom.
> Najwyraźniej korzystasz z jakiejś biblioteki.

No dobra... to ja mam taki kod, ktory dziala bezblednie. Nie udalo mi
sie przetestowac na ie (bo go nie mam), ale na ff dziala bez
zarzutu... Nie dolaczam zadnych plikow js, wiec kod nie korzysta z
dodatkowych bibliotek...

function Node() {
	this.getNazwa = function() {
		return "Node.getNazwa";
	};

	this.dodaj = function(nodeObj) {
		alert(nodeObj.getNazwa());
	};
}

function Kategoria() {
	this.inheritFrom = Node;
	this.inheritFrom();

	this.getNazwa = function() {
		return "Kategoria.getNazwa";
	};

}

wywoluje tak:

var kat1 = new Kategoria();
var kat2 = new Kategoria();

kat1.dodaj(kat2); // dostaje alerta z 'Kategoria.getNazwa'

var node1 = new Node();
var node2 = new Node();

node1.dodaj(node2); // dostaje alerta z 'Node.getNazwa'

Bede wdzieczna za info, jesli to nie jest czesc jezyka js, to jakim
cudem dziala? Dodam ze korzystalam ze wskazowek zawartych na tej
stronie:
http://www.webreference.com/js/column79/3.html

mmiarecka pisze:
> function Kategoria() {
> 	this.inheritFrom = Node;
> 	this.inheritFrom();

this.sratatata = Node;
this.sratatata();
Też zadziała ;)

> 	this.getNazwa = function() {
> 		return "Kategoria.getNazwa";
> 	};
> 
> }


-- 
message[autor="PablO"]::after {
	content:"Pozdrawiam";
}

On 16 Lip, 12:21, Paweł Piskorz <nie.ma.ma...@psikre.nie?> wrote:
> this.sratatata = Node;
> this.sratatata();
> Też zadziała ;)

lol... faktycznie :P

No dobra... ktos sie pokusi o wytlumaczenie mi ki diabel? W Javie
takie hocki nie dzialaja :/ Ja wiem, ze JavaScript to nie Java, ale
nie mam innego punktu oparcia jesli chodzi o obiektowosc...

On 16 Lip, 09:36, mmiarecka <mmiare...@gmail.com> wrote:
> Bede wdzieczna za info, jesli to nie jest czesc jezyka js, to jakim
> cudem dziala? Dodam ze korzystalam ze wskazowek zawartych na tej
> stronie:http://www.webreference.com/js/column79/3.html

Paweł już Ci to wyjaśnił, ja natomiast jeszcze zwracam uwagę na to, że
przesłaniasz (o ile to kod dla przeglądarki) wbudowany obiekt Node.

--
marcoos.com

On 16 Lip, 13:02, marcoos <marek.step...@gmail.com> wrote:
[...]
> ja natomiast jeszcze zwracam uwagę na to, że
> przesłaniasz (o ile to kod dla przeglądarki) wbudowany obiekt Node.

Wiem, wiem :)

Natomiast ciagle mam problem z ogarnieciem modyfikatorow dostepu...
Jedno z przykladowych zadan, ktore znalazlam w necie:
"zaimplementuj mi klase X, ktora dziedziczy po Y, ktora ma properties
prywatna Z i protected V". O ile z dziedziczeniem i prywatnymi
wlasciwosciami nie mam wiekszego problemu o tyle protected zaczyna mi
sie snic po nocach w roli koszmaru...

On 16 Lip, 13:25, mmiarecka <mmiare...@gmail.com> wrote:
> Natomiast ciagle mam problem z ogarnieciem modyfikatorow dostepu...

A to jest bardzo proste: nie ma żadnych "modyfikatorów dostępu". :)

> Jedno z przykladowych zadan, ktore znalazlam w necie:
> "zaimplementuj mi klase X, ktora dziedziczy po Y, ktora ma properties
> prywatna Z i protected V". O ile z dziedziczeniem i prywatnymi
> wlasciwosciami nie mam wiekszego problemu o tyle protected zaczyna mi
> sie snic po nocach w roli koszmaru...

Nie ma klas w JavaScripcie, ani nie ma pól o dostępie "protected" (ani
niczego specjalnie podobnego). Samo sformułowanie takiego zadania,
jeśli dotyczy JS, świadczy o tym, że jego autor nie ma pojęcia, o co
chodzi. :)

W JS nie ma także zmiennych prywatnych. To, co dla uproszczenia (czy
zagmatwania, jak tutaj) nazywa się "zmiennymi prywatnymi" jakiejś
"klasy", to zwykłe zmienne lokalne jakiejś funkcji, na przykład
konstruktora. Można by też przeprowadzić akademicką dyskusję na temat,
czy to, co nazywamy "zmiennymi publicznymi" w JS spełnia definicję
zmiennej publicznej takiej jak w C++ czy Javie. :)

Tak jak napisałem - jedyną hermetyzacją w JS są zasięgi funkcji
(closures). Przy ich pomocy można do pewnego stopnia imitować zmienne
"prywatne" przy dzięki temu, jak zachowują się zmienne lokalne
funkcji.

--
marcoos.com

On 16 Lip, 07:44, "William Bonawentura" <n...@ipartners.pl> wrote:
> > Jedynym sposobem hermetyzacji w JS są closures, czyli zasięgi funkcji,
> Jesteś absolutnie pewnym ? :)

A masz kontrprzykład? Nie sądzę. :)

--
marcoos.com

On 16 Lip, 09:36, mmiarecka <mmiare...@gmail.com> wrote:
> Bede wdzieczna za info, jesli to nie jest czesc jezyka js, to jakim
> cudem dziala? Dodam ze korzystalam ze wskazowek zawartych na tej
> stronie:http://www.webreference.com/js/column79/3.html

Wcale nie działa. Owszem, coś tam robi, ale nie to, czego tak naprawdę
chcesz. :)

function Kategoria() {
         this.inheritFrom = Node;
         this.inheritFrom();
}

Co tu zostało zrobione: funkcja-konstruktor o (nieszczęśliwej,
konfliktogennej) nazwie "Node" została przypisana do tworzonego
obiektu pod dziwną i niepasującą nazwą "inheritFrom" i zaraz potem
wywołana. Dzięki temu wprawdzie "this" w tak wywołanej funkcji Node
wskazuje na właściwy obiekt (ten sam this, co wewnątrz konstruktora
Kategoria), ale nie zostanie zachowana hierarchia prototypów.

k = new Kategoria();
alert(k instanceof Node); // false

Ponadto to całe "inheritFrom" wykonuje się (zupełnie niepotrzebnie)
przy każdej instancjacji konstruktora Kategoria. Nie ma to sensu -
szkoda czasu i pamięci.

Dlatego prawidłowo powinno być:

function Kategoria() {
        // zakładam, że ma to być funkcja "priviledged"; jeśli nie,
        //to powinna być zdefiniowana w prototypie
        this.getNazwa = function() {
                return "Kategoria.getNazwa";
        };
}
Kategoria.prototype = new Node();

W ten sposób prototyp Kategorii jest instancją Node (i tylko raz
zostanie ona zinstancjowana do celów dziedziczenia w Kategorii), a
hierarchia prototypów zostanie zachowana:

k = new Kategoria();
alert(k instanceof Node); // true

Tak działa (pseudo-)klasyczne dziedziczenie w JS. Niektórzy piszą
sobie jakieś funkcje, które to upraszczają (metoda
Function.prototype.method proponowana przez Crockforda, kiedy jeszcze
nie był wrogiem udawania "klasowości" ;)), Prototype.js i inne
biblioteki dostarczają odpowiedni cukier składniowy, ale zasada jest
ta sama.

Inna sprawa, że można sobie całkowicie poradzić (prawie) bez
konstruktorów i operatora new, odchodząc od udawania Javy. Zob.
http://javascript.crockford.com/prototypal.html :)

--
marcoos.com

Użytkownik "marcoos" <marek.stepien@gmail.com> napisał w wiadomości 
news:eb247ef3-ba6f-4d85-ab8b-8c8a84181620@o7g2000yqb.googlegroups.com...
On 16 Lip, 07:44, "William Bonawentura" <n...@ipartners.pl> wrote:
> > Jedynym sposobem hermetyzacji w JS są closures, czyli zasięgi funkcji,
> Jesteś absolutnie pewnym ? :)

A masz kontrprzykład? Nie sądzę. :)


Np. konwencja nazewnicza. Albo kontrola "isinstance" dla this wewnątrz 
chronionej metody. 

On 16 Lip, 20:14, marcoos <marek.step...@gmail.com> wrote:
> Wcale nie działa. Owszem, coś tam robi, ale nie to, czego tak naprawdę
> chcesz. :)

Do tego juz w miedzy czasie doszlam sama :) ale i tak dziekuje za
opisanie slowami tego, co gdzies tam pod skora czulam :)

Ciezko sie walczy z JS majac nalecialosci z Javy... To dwa rozne
swiaty.

On 16 Lip, 19:53, marcoos <marek.step...@gmail.com> wrote:
> On 16 Lip, 13:25, mmiarecka <mmiare...@gmail.com> wrote:
>
> > Natomiast ciagle mam problem z ogarnieciem modyfikatorow dostepu...
>
> A to jest bardzo proste: nie ma żadnych "modyfikatorów dostępu". :)
>
> > Jedno z przykladowych zadan, ktore znalazlam w necie:
> > "zaimplementuj mi klase X, ktora dziedziczy po Y, ktora ma properties
> > prywatna Z i protected V". O ile z dziedziczeniem i prywatnymi
> > wlasciwosciami nie mam wiekszego problemu o tyle protected zaczyna mi
> > sie snic po nocach w roli koszmaru...
>
> Nie ma klas w JavaScripcie, ani nie ma pól o dostępie "protected" (ani
> niczego specjalnie podobnego). Samo sformułowanie takiego zadania,
> jeśli dotyczy JS, świadczy o tym, że jego autor nie ma pojęcia, o co
> chodzi. :)

Powiem tak - tez mi sie tak wydaje, ale ja jestem ciagle zielona w js
wykraczajacym poza operowanie na strukturze DOM. Zadanie, ktore
przytoczylam dostalam od rekrutera jak przyklad tego co mnie czeka na
tescie rekrutacyjnym...

> W JS nie ma także zmiennych prywatnych. To, co dla uproszczenia (czy
> zagmatwania, jak tutaj) nazywa się "zmiennymi prywatnymi" jakiejś
> "klasy", to zwykłe zmienne lokalne jakiejś funkcji, na przykład
> konstruktora. Można by też przeprowadzić akademicką dyskusję na temat,
> czy to, co nazywamy "zmiennymi publicznymi" w JS spełnia definicję
> zmiennej publicznej takiej jak w C++ czy Javie. :)
>
> Tak jak napisałem - jedyną hermetyzacją w JS są zasięgi funkcji
> (closures). Przy ich pomocy można do pewnego stopnia imitować zmienne
> "prywatne" przy dzięki temu, jak zachowują się zmienne lokalne
> funkcji.

To juz opanowalam, umiem swobodnie zbudowac lancuch dziedziczenia, z
uzyciem wlasciwosci "publicznych" i "prywatnych". Teraz pozostaje mi
przekonanie rekrutera :P

Dziekuje marcoos, Twoje wypowiedzi bardzo duzo mi daly.

On 17 Lip, 09:31, "William Bonawentura" <n...@ipartners.pl> wrote:
> > > Jedynym sposobem hermetyzacji w JS są closures, czyli zasięgi funkcji,
> > Jesteś absolutnie pewnym ? :)
>
> A masz kontrprzykład? Nie sądzę. :)
>
> Np. konwencja nazewnicza.

Konwencja nazewnicza jest tylko konwencją. Owszem, często jest to
najlepsze i najprostsze rozwiązanie, ale nikt nie broni złamać
konwencji
i pisać do "prywatnych" własności z podkreśleniem w nazwie. :)

> Albo kontrola "isinstance" dla this wewnątrz chronionej metody.

isinstance brzmi jak Python, miałeś chyba na myśli instanceof. :)

Nie nazwałbym tego jednak hermetyzacją - metoda dalej jest dostępna,
tylko zmieniasz jej zachowanie.:)

--
marcoos.com

Użytkownik "marcoos" <marek.stepien@gmail.com> napisał w wiadomości 
news:3ff4d8a4-6862-4933-aedd-a7c3f58ba854@b14g2000yqd.googlegroups.com...
> Konwencja nazewnicza jest tylko konwencją. Owszem, często jest to
> najlepsze i najprostsze rozwiązanie, ale nikt nie broni złamać
> konwencji
> i pisać do "prywatnych" własności z podkreśleniem w nazwie. :)

Reguła dla kompilatora też jest tylko konwencją - nie pozwala na defaultowe 
skompilowanie kodu z takim odwołaniem. Kto chce wykona metodę "hackiem". W 
technice closures też możesz odczytać źródło funkcji i wykonać ją evalem.

On 17 Lip, 13:38, "William Bonawentura" <n...@ipartners.pl> wrote:
> Reguła dla kompilatora też jest tylko konwencją - nie pozwala na defaultowe
> skompilowanie kodu z takim odwołaniem. Kto chce wykona metodę "hackiem". W
> technice closures też możesz odczytać źródło funkcji i wykonać ją evalem.

Nie będzie to możliwe w ECMAScripcie 5 z dyrektywą "use strict".

--
marcoos.com