Czy możliwe jest utworzenie "słabego odniesienia" w javascript?

Podczas uruchamiania JS na NodeJS możesz rozważyć https://github.com/TooTallNate/node-weak .

Prawdziwe słabe odniesienia, Nie, jeszcze nie (ale twórcy przeglądarek patrzą na temat). Ale tutaj jest pomysł, jak symulować słabe odniesienia.

Możesz zbudować pamięć podręczną, przez którą przejeżdżasz obiekty. Gdy obiekt jest przechowywany, pamięć podręczna przechowuje prognozę, ile pamięci obiekt zajmie. W przypadku niektórych elementów, takich jak przechowywanie obrazów, jest to proste. Dla innych byłoby to trudniejsze.

Gdy potrzebujesz obiektu, następnie pytaj cache o to. Jeśli bufor posiada obiekt, jest on zwracany. Jeżeli go tam nie ma, wtedy element zostanie wygenerowany, zapisany, a następnie zwrócony.

Słabe odwołania są symulowane przez usuwanie elementów pamięci podręcznej, gdy całkowita ilość przewidywanej pamięci osiągnie określony poziom. Będzie przewidywać, które przedmioty są najmniej używane na podstawie tego, jak często są one pobierane, ważone przez to, jak dawno temu zostały zabrane. Można również dodać koszt "kalkulacji", jeśli kod, który tworzy element, zostanie przekazany do pamięci podręcznej jako zamknięcie. Pozwoli to pamięci podręcznej na przechowywanie elementów, które są bardzo drogie w budowie lub generowaniu.

Algorytm usuwania jest kluczowy, ponieważ jeśli się pomylisz, możesz w końcu usunąć najpopularniejsze elementy. Spowodowałoby to fatalną wydajność.

Tak długo, jak cache jest jedynym obiektem z trwałymi referencjami do przechowywanych obiektów, to powyższy system powinien działać całkiem dobrze jako alternatywa dla prawdziwych słabych referencji.

Tylko dla odniesienia; JavaScript go nie ma, ale ActionScript 3 (który jest również ECMAScript) tak. Sprawdź parametr konstruktora dla słownika .

Użycie mechanizmu buforowania do emulowania słabego odniesienia, jak jl235 zasugerował powyżej , jest rozsądne. Jeśli słabe odniesienia istniałyby natywnie, można zaobserwować takie zachowanie:

this.val = {};
this.ref = new WeakReference(this.val);
...
this.ref.get(); // always returns val
...
this.val = null; // no more references
...
this.ref.get(); // may still return val, depending on already gc'd or not

Natomiast z cache ' EM można zaobserwować:

this.val = {};
this.key = cache.put(this.val);
...
cache.get(this.key); // returns val, until evicted by other cache puts
...
this.val = null; // no more references
...
cache.get(this.key); // returns val, until evicted by other cache puts

Jako posiadacz referencji, nie powinieneś zakładać, kiedy odnosi się do wartości, nie inaczej jest używając bufora

EcmaScript 6 (ES) posiada obiekt WeakMap . Obsługa przeglądarek wśród nowoczesnych przeglądarek jest Całkiem dobra (obsługują ją Ostatnie 3 wersje Firefoksa, chrome, a nawet nadchodząca wersja IE).

Http://www.jibbering.com/faq/faq_notes/closures.html

ECMAScript wykorzystuje automatyczne usuwanie śmieci. Specyfikacja nie definiuje szczegółów, pozostawiając to implementatorom do uporządkowania, a niektóre implementacje są znane z tego, że dają bardzo niski priorytet ich operacjom usuwania śmieci. Ale ogólna idea jest taka, że jeśli obiekt staje się nie-odwołalny (przez brak pozostałych odniesień do niego dostępnych dla kodu wykonującego) staje się Dostępny dla śmieci zbieranie i będzie w przyszłości niszczone, a wszelkie zużywane zasoby uwolnione i zwrócone do systemu w celu ponownego wykorzystania.

Zwykle ma to miejsce po wyjściu z kontekstu wykonania. Struktura łańcucha zakresu, obiekt aktywacji/zmiennej i wszelkie obiekty utworzone w kontekście wykonania, w tym obiekty funkcji, nie byłyby już dostępne, a zatem stałyby się dostępne do zbierania śmieci.

Czyli nie ma słabych tylko tych, których nie dłużej stają się dostępne.