А можно ли узнать количествоекземпляров обьекта ?

Бочонок

http://frontender.info
А можно ли узнать количествоекземпляров обьекта ?

Доброго времени суток.

Я создал класс и некоторое число его экземпляров.
Скажите а можно ли узнать количество экземпляров и получить ссылки на них стандартными методами?
Или это возможно только добавляя в прототипе в масив экземпляры и увеличивая при создании нового некую переменную в прототипе на еденицу ?
 

Crazy

Developer
Re: А можно ли узнать количествоекземпляров обьекта ?

Автор оригинала: Бочонок
Или это возможно только добавляя в прототипе в масив экземпляры и увеличивая при создании нового некую переменную в прототипе на еденицу ?
...и ТАК это ты тоже не сможешь сделать. Точнее, добавляя экземпляры в массив ты обеспечишь себе утечку памяти, поскольку заблокируешь работу сборщика мусора.

А если не будешь добавлять в массив ссылки, то твой счетчик будет врать, поскольку не будет знать ничего о том, что объекту уничтожены сборщиком мусора.

И самое важное: для решение какой загадочной проблемы потребдовалось абстрактное знание о количестве объектов?
 

Бочонок

http://frontender.info
Эээээ....
Экземпляры могут генерировать блок с id, которые я хотел сделать вида

"nest"+номер экземпляра.

Это обеспечило бы уникльность id и возможность удобной работы с этими блоками. (Зная их количество и порядковый номер нужного получить id этого блока просто, как и при необходимости "перебрать" все блоки).

Ссылки на экземпляры нужны для того что бы можно было "перебрать" все экземпляры и получить от них уникальную для каждого екземпляра информацию.

Так что, совершенно не возможно:
1. узнать количество екземпляров класса.
2. получить масив, со ссылками на каждый екземпляр.
?

Совсем никак ?

Или янеправильно ставлю вопрос, и такие задачи решаются совершенно по другому?
 

Crazy

Developer
1. Что мешает просто делать счетчик и последовательно инкрементировать его, использовуя значения для формирования id?

Но:

2. Для решения какой задачи вдруг потребовалась абстрактная операция перебора всех объектов?
 

Бочонок

http://frontender.info
1. Ничего. Спасибо за совет.
Счетчик может хранится в классе ?
Проблема утечки памяти связана только с помещением в него экземпляров, насколько я понял?

2. Гм. Да в общем то пока что для абстрактной.
Но я думаю что ситуация когда возникнет необходимость получиьт данные от всех экземпляров вполне вероятна.
Наиболее банальный пример -
у меня есть класс - книга.
у каждой книги есть цена.
Пользователь наштамповал их незнамо сколько.
И тут, перед отправкой данных на сервер, пользователю захотелось узнать среднюю цену наштампованого.
Без перебора всех книг и получения от них цены каждой книги не обойдешься.
Точнее обойдешься,если очень захочешь (например добавляя стоимость при создании книги и вычитая при удалении), но задачи всегда можно решить более чем одним способом.

Я понимаю что пример "христоматийный" и мало напоминает реальные проблемы. Но он показыват, что такая задача в теории возможна.

1. Насколько я понял сохраняю я экземпляры внутри или вне класса - все равно.
Это грозит утечкой памяти, верно ?

2. Есть ли решение этой проблемы, не череватое утечкой памяти ? Или эта проблема надумана, не имеет никакого отношения к реальному положению вещей и о ней лучше забыть ? Другими словами, то что я спрашиваю это такой же бред как и длинна ассоциативного массива ?

P.S. Извините за назойливость.
Решил переписать пару библиотек с использованием OOP в JS, за одно выясняю, а на что он собственно способен и что с ним можно сделать лучше.
 

Crazy

Developer
Автор оригинала: Бочонок
Пользователь наштамповал их незнамо сколько.
Не бывает. Объект делается для какой-то конкретной цели и передается на хранение какому-то конкретному владельцу. Вот у этого владельца и можно получить список.

В том варианте, который ты намереваешься сделать, ты неизбежно огребешь проблемы. К примеру, если у тебя пользователь отказался от какой-то книги, то ты по прежнему будешь учитывать ее стоимость при вычислении.
 

Бочонок

http://frontender.info
Объект делается для какой-то конкретной цели и передается на хранение какому-то конкретному владельцу
Обьясни, пожалуста, что ты подразумеваешь под владельцем ?

если у тебя пользователь отказался от какой-то книги, то ты по прежнему будешь учитывать ее стоимость при вычислении
Почему ? Если пользователь удаляет обьект книги, то как она может присутствовать при переборе экземпляров ?

Я даже статью где на похожуюю тематику читал.
Одну секунду - погуглю.

-~{}~ 28.08.06 13:04:

Вот! Нашел, где я подобное видел!
http://www.sitepoint.com/article/oriented-programming-2
У автора тот же неверный подход, или я просто не понял о чем он писал ?

-~{}~ 28.08.06 13:05:

Откуда появляется ошибка, если при удалении книги мы удаляем ее из массива ?
 

Crazy

Developer
Автор оригинала: Бочонок
Обьясни, пожалуста, что ты подразумеваешь под владельцем ?
Того, в кого она аггрегирована. Как у нас с ООП?

Почему ? Если пользователь удаляет обьект книги, то как она может присутствовать при переборе экземпляров ?
А как ты собираешься "абстрактно удалять" книгу? В JS объекты удаляет сборщик мусора. Когда сочтет нужным.

Вот! Нашел, где я подобное видел!
http://www.sitepoint.com/article/oriented-programming-2
У автора тот же неверный подход, или я просто не понял о чем он писал ?
В этом примере нет никакого "списка книг вообще". Есть класс Library. Ты можешь создать любое количество объектов этого класса. Каждому будет принадлежать свой список книг. И по каждому в отдельностпи будет считаться среднее.

Это разумное, стандартное решение.

Откуда появляется ошибка, если при удалении книги мы удаляем ее из массива ?
Если ты говоришь о той реализации, в которой все созданные объекты вручную регистрируются в массиве -- да, ЭТОЙ ошибки не будет. Но будет другая: если, к примеру, у тебя часть объектов Книга создается пользователем, а часть -- системой для каких-то других целей. А суммироваться всегда будет полный список. Что явно нелепо.
 

Бочонок

http://frontender.info
Того, в кого она аггрегирована. Как у нас с ООП?
У меня определенно наблюдаются некоторые проблемы с терминологией.
Ты не мог бы пояснить ?
Если можно кодом...
Если нельзя - тыкни меня, пожалуста, носом, где посмотреть.

А как ты собираешься "абстрактно удалять" книгу? В JS объекты удаляет сборщик мусора. Когда сочтет нужным.
А разве нельзя сделать это с помощью delete ?
The delete operator deletes an object, an object's property, or an element at a specified index in an array.
из Core JavaScript Reference 1.5

В этом примере нет никакого "списка книг вообще". Есть класс Library.
Класс Library содержит массив books, в котором хранятся ссылки на экземпляры класса Book.
Что же это, как не список книг ?
И есть ли разница, хранить этот список в новом классе (Library) или в классе Book, только только используяя прототип (правда в данном конкретном примере это несколько нелогично - книга содержит библиотеку, а не наоборот)?
Например так: (Код в конце поста).
Или именно такое хранение данных и вызовет утечку памяти ?
Тогда такой список можно хранить только во внешних обьектах ?

если, к примеру, у тебя часть объектов Книга создается пользователем, а часть -- системой для каких-то других целей. А суммироваться всегда будет полный список. Что явно нелепо.
А почему нельзя разделить "системные" книги и "пользовательские" каким то свойством ? Например book_type = 'system' || 'user' ?


PHP:
function book(title,price){
	this.title = title;
	this.price = price;
	
	
	if(book.prototype.count==undefined){
		book.prototype.count=1;
	}else{
		book.prototype.count++;
	}

	if(book.prototype.library==undefined){
		book.prototype.library = new Array();
		book.prototype.library[title] = this;
	}else{
		book.prototype.library[title] = this;
	}

	this.mid_price = function(){
		var sum = new Number(0);
		for (var i in this.library) {
			sum+=this.library[i].price;
		}
		var mid = Math.round(sum/this.count);
		return mid;
	}

	this.delete_book = function(){
		book.prototype.count--;
		delete this.library[this.title];
	}

}
r1= new book('book1',30);
r2= new book('book2',20);
r3= new book('book3',60);
alert(r1.mid_price());
r3.delete_book();
delete r3;
alert(r1.mid_price());
P.S. Удалить обьект из него самого невозможно ?
 

Crazy

Developer
Автор оригинала: Бочонок
из Core JavaScript Reference 1.5
Обрати внимание: здесь вовсе не сказано, что объект будет немедленно удален из памяти.

Класс Library содержит массив books, в котором хранятся ссылки на экземпляры класса Book.
Что же это, как не список книг ?
Это список книг. У тебя есть в этом сомнения?

И есть ли разница, хранить этот список в новом классе (Library) или в классе Book, только только используяя прототип
Разнича описана в моем предыдущем сообщении. См. вокруг слова "Library".

А почему нельзя разделить "системные" книги и "пользовательские" каким то свойством ? Например book_type = 'system' || 'user' ?
Можно. Если в этом есть смысл. Если задаться маниакальной идеей хранить все объекты в едином списке и каждый раз их в нем искать -- можно найти способ технической реализации.

Можно красить яйца в зеленый цвет? Можно. Нужно? Лично я необходимости не вижу. Но если кто-то ощущает острую потребность -- почему бы и нет.
 

Бочонок

http://frontender.info
Обрати внимание: здесь вовсе не сказано, что объект будет немедленно удален из памяти.
Тоесть обьект остается в памяти, пока его не уберет сборщика мусора?


Если не сложно, помоги подвести итог. ПОООЖЖЖЖААААЛУСТА:

1. Можно создать такой список книг и поддерживать его в ручную, но РАЗУМНО и УДОБНО хранить его в другом классе (и так же поддерживать вручную).

2. Описаное выше извращени НЕ НАРУШИТ работу сборщика мусора.

3. Способ с хранением списка обьектов в другом классе НЕ НАРУШИТ работу сборщика мусора.

4. В JavaScript НЕЛЬЗЯ сделать тоже самое методами самого JS и НЕ вручную.

5. delete удаляет обьект не из памяти, а из пространства имен ? или откуда ?

6. В JS НЕЛЬЗЯ удалить обьект из него самого.
 

Crazy

Developer
Автор оригинала: Бочонок
Тоесть обьект остается в памяти, пока его не уберет сборщика мусора?
Насколько я знаю -- да.

1. Можно создать такой список книг и поддерживать его в ручную, но РАЗУМНО и УДОБНО хранить его в другом классе (и так же поддерживать вручную).
В большинстве случаев разумно и удобно хранить его в другом классе.

2. Описаное выше извращени НЕ НАРУШИТ работу сборщика мусора.
Если ты явно делаешь delete и убираешь из массива -- не должно.

3. Способ с хранением списка обьектов в другом классе НЕ НАРУШИТ работу сборщика мусора.
...поскольку с точки зрения движка между этими способами нет никакой разницы.

4. В JavaScript НЕЛЬЗЯ сделать тоже самое методами самого JS и НЕ вручную.
Если я правильно понимаю, что ты назвал "то же самое" -- да.

5. delete удаляет обьект не из памяти, а из пространства имен ? или откуда ?
Delete сообщает движку, что скрипту объект более не нужен. Что он при этом -- и как -- делает ты можешь узнать только из исходников.

6. В JS НЕЛЬЗЯ удалить обьект из него самого.
Понятия не имею. Не помню, чтобы у меня когда-либо возникала такая потребность.
 

Бочонок

http://frontender.info
Спсибо большое за то, что потратил на мой вопрос столько времени.
Ты мне очень помог.
 
Сверху