Обсуждение:Введение, или краткий обзор - История изменений

Korvin: /* Re */

2008-04-29T16:53:04Z

‎Re

Korvin: /* И еще Ре */

2008-04-25T15:27:31Z

‎И еще Ре

Korvin: /* И еще Ре */

2008-04-25T15:26:26Z

‎И еще Ре

Korvin: И еще Ре

2008-04-25T15:25:21Z

И еще Ре

Root: /* Re */

2008-04-25T15:17:14Z

‎Re

Root: Re

2008-04-25T15:17:00Z

213.180.219.90: /* Re */

2008-04-25T14:09:04Z

‎Re

Korvin: /* Re */

2008-04-25T13:52:43Z

‎Re

Korvin в 12:44, 25 апреля 2008

2008-04-25T12:44:17Z

Korvin в 12:42, 25 апреля 2008

2008-04-25T12:42:14Z

@@ Строка 42: / Строка 42: @@
 Ну или другой вариант: другая библиотека присылает некий контейнер, который приходится использовать в текущем модуле. Но вот беда, язык на котором написан "тот" модуль понятия не имеет о замыканиях и соответственно ни о каком методе each() не знает (скажем, используется принцип search-valid-next). А нам таки хочется пользоваться всеми преимуществами примеси Enumerable. Тогда берем и расширяем класс методом each() и добавляем в родители соответствующую примесь:
- extend TheirWeirdCollection extends Enumerable {
+<source lang="kpp">
-     public const function each(block b) {
+extend TheirWeirdCollection extends Enumerable {
-         for(this.search(); this.valid(); this.next())
+    public const function each(block b) {
-             b(this.current());
+        for(this.search(); this.valid(); this.next())
+            b(this.current());
-−
+    }
 И радуемся жизни:
- var col = SomeMethod(); //скажем, возвращает этот самый TheirWeirdCollection
+<source lang="kpp">
- var result = col.select() { |x| x > 5; }; //применяем примесь
+var col = SomeMethod(); //скажем, возвращает этот самый TheirWeirdCollection
- result.each() { |x| puts(x); } //тут уже конечно не TheirWeirdCollection, а array
+var result = col.select() { |x| x > 5; }; //применяем примесь
 А для написания основного кода надо использовать наследование, как и положено.

@@ Строка 102: / Строка 102: @@
 Ну при таком раскладе конечно, возможны странные явления. Которые, впрочем, все равно жестко детерминированы и определяются порядком импортирования модулей в третьем модуле. К тому же, как сказал _root, компилятор это дело отловит. Но это уже относится к логике разработки софта. Подобные казусы могут быть и без расширений. Вообще, если разработчик (первого/второго модулей) не индус, то он мог бы (и должен был бы) объявить это расширение приватным. Соответственно, оно распространяется только на сам модуль, но не на модули, его импортирующие. Повторюсь: как правило, расширения применяются "для личного удобства". Если же оно выносится в интерфейс, то это должно оговариваться отдельно (и вообще говоря, тут уже надо наследовать, а не расширять).
-В общем и целом, мне кажется что это проблемы идеологии а не инструментов. Любой инструмент может быть использован вовред, и упрекать за это надо человека. Это все равно что утверждать, что С++ это отстой только потому что там можно записать в произвольный блок памяти и уронить систему.
+В общем и целом, мне кажется что это проблемы идеологии а не инструментов. Любой инструмент может быть использован вовред, и упрекать за это надо человека. Это все равно что утверждать, что С++ это отстой только потому что там можно записать в произвольный блок памяти и уронить программу.
 --[[Участник:Korvin|Korvin]] 11:26, 25 апреля 2008 (EDT)

@@ Строка 100: / Строка 100: @@
 == И еще Ре ==
-Ну при таком раскладе конечно, возможны странные явления. Которые, впрочем, все равно жестко детерминированы и определяются порядком импортирования модулей в третьем модуле. Но это уже относится к логике разработки софта. Подобные казусы могут быть и без расширений. Вообще, если разработчик (первого/второго модулей) не индус, то он мог бы (и должен был бы) объявить это расширение приватным. Соответственно, оно распространяется только на сам модуль, но не на модули, его импортирующие. Повторюсь: как правило, расширения применяются "для личного удобства". Если же оно выносится в интерфейс, то это должно оговариваться отдельно (и вообще говоря, тут уже надо наследовать, а не расширять).
+Ну при таком раскладе конечно, возможны странные явления. Которые, впрочем, все равно жестко детерминированы и определяются порядком импортирования модулей в третьем модуле. К тому же, как сказал _root, компилятор это дело отловит. Но это уже относится к логике разработки софта. Подобные казусы могут быть и без расширений. Вообще, если разработчик (первого/второго модулей) не индус, то он мог бы (и должен был бы) объявить это расширение приватным. Соответственно, оно распространяется только на сам модуль, но не на модули, его импортирующие. Повторюсь: как правило, расширения применяются "для личного удобства". Если же оно выносится в интерфейс, то это должно оговариваться отдельно (и вообще говоря, тут уже надо наследовать, а не расширять).
 В общем и целом, мне кажется что это проблемы идеологии а не инструментов. Любой инструмент может быть использован вовред, и упрекать за это надо человека. Это все равно что утверждать, что С++ это отстой только потому что там можно записать в произвольный блок памяти и уронить систему.

← Предыдущая		Версия 15:25, 25 апреля 2008
Строка 97:		Строка 97:

	--[[Участник:Root\|_root]] 11:17, 25 апреля 2008 (EDT)		--[[Участник:Root\|_root]] 11:17, 25 апреля 2008 (EDT)
		+
		+	== И еще Ре ==
		+
		+	Ну при таком раскладе конечно, возможны странные явления. Которые, впрочем, все равно жестко детерминированы и определяются порядком импортирования модулей в третьем модуле. Но это уже относится к логике разработки софта. Подобные казусы могут быть и без расширений. Вообще, если разработчик (первого/второго модулей) не индус, то он мог бы (и должен был бы) объявить это расширение приватным. Соответственно, оно распространяется только на сам модуль, но не на модули, его импортирующие. Повторюсь: как правило, расширения применяются "для личного удобства". Если же оно выносится в интерфейс, то это должно оговариваться отдельно (и вообще говоря, тут уже надо наследовать, а не расширять).
		+
		+	В общем и целом, мне кажется что это проблемы идеологии а не инструментов. Любой инструмент может быть использован вовред, и упрекать за это надо человека. Это все равно что утверждать, что С++ это отстой только потому что там можно записать в произвольный блок памяти и уронить систему.

← Предыдущая		Версия 15:17, 25 апреля 2008
Строка 95:		Строка 95:

	ЗЫ. По поводу всей системы предлагаю закончить тут флуд, либо перенести его на форум или в обсуждения блоговых записей.		ЗЫ. По поводу всей системы предлагаю закончить тут флуд, либо перенести его на форум или в обсуждения блоговых записей.
		+
		+	--[[Участник:Root\|_root]] 11:17, 25 апреля 2008 (EDT)

← Предыдущая		Версия 15:17, 25 апреля 2008
Строка 87:		Строка 87:

	ЗЗЫ Не первый год пишу high load системы. Те куски информации что есть на вашем сайте вызывают сомнение что система вобще взлетит под хоть какойнибудь нагрузкой. Подроный анализ делать лень. Тем болие что не все подсистемы описаны.		ЗЗЫ Не первый год пишу high load системы. Те куски информации что есть на вашем сайте вызывают сомнение что система вобще взлетит под хоть какойнибудь нагрузкой. Подроный анализ делать лень. Тем болие что не все подсистемы описаны.
		+
		+	== Re ==
		+
		+	Скажем так. На уровне виртуальной машины - будет использован тот метод, который загружен последним, т.е. из того модуля, который идет последним в списке импорта. Но это если писать на [[Описание платформы Gide\|гайд-ассемблере]].
		+
		+	K++ просто ругнется ошибкой method redefinition. На этапе компиляции вся информация о методах есть.
		+
		+	ЗЫ. По поводу всей системы предлагаю закончить тут флуд, либо перенести его на форум или в обсуждения блоговых записей.

← Предыдущая		Версия 14:09, 25 апреля 2008
Строка 59:		Строка 59:

	--[[Участник:Korvin\|Korvin]] 09:52, 25 апреля 2008 (EDT)		--[[Участник:Korvin\|Korvin]] 09:52, 25 апреля 2008 (EDT)
		+
		+	== Re ==
		+	Еще раз:
		+
		+	Модуль А и модуль Б созданны '''независимыми''' разработчиками. Они друг о друге вобще ничего не знают.
		+
		+	Соответственно упорядочить модули А и Б друг относительно друга невозможно.
		+
		+	Они расширили один и тотже класс одним и темже методом.
		+
		+	Теперь третий разработчик импортировал оба модуля А и Б.
		+
		+	Чей метод будет использован?
		+
		+
		+	Сердитый Ученый.
		+
		+	ЗЫ Чем дальше тем сильнее прихожу к выводу что наследование реализаций это вобще зло. Ибо очень сильно связывает систему. ИМХО можно использовать только наследование интерфейсов. Тогда система остается в управляемом состоянии гораздо дольше.
		+
		+	Чтобы не дублировать код можно завести 3 сущьности:
		+
		+	1)Интерфейс. Чистый контракт без каких либо намеков на реализацию.
		+
		+	2)Миксин. Может содержать код и данные. Реализует один или несколько интерфейсов. Может требовать чтобы использующий его тип реализовал один или несколько других интерфейсов нужных миксину для работы.
		+
		+	3)Тип. Может содержать код и данные. Может агрегировать миксины. Реализует один или несколько интерфейсов. Тип расширять нельзя. Ни наследованием ни добавление методов.
		+
		+	ЗЗЫ Не первый год пишу high load системы. Те куски информации что есть на вашем сайте вызывают сомнение что система вобще взлетит под хоть какойнибудь нагрузкой. Подроный анализ делать лень. Тем болие что не все подсистемы описаны.

@@ Строка 39: / Строка 39: @@
 Использован будет последний, то есть последний перекрывает всех предыдущих. И действовать будут естественно в рамках модуля, объявившего данное расширение и всех модулях, которые его используют. Видать примеры в книге корявые, надо придумать что нибудь более реальное.
 В целом, расширения не предназначены для написания фундаментального кода. Основная идея в том, чтобы можно было подкрутить класс "под себя", без необходимости перелопачивать код. Ориентировка на то, что тебе дали объект, но ты хочешь от него чего то еще. Если проводить аналогию с тем же Ruby. Тебе возвращают объект, но ты хочешь чтобы он умел производить с собой некоторые действия, скажем выводить некоторую информацию (инспектировать себя). И эту информацию ты используешь в своем коде. Тогда просто создается расширение в котором объявляется необходимый метод. Притом что оно никоим образом не мешает другим пользователям (которые так же могут у себя делать расширения). Альтернатива этому подходу -- написание врапперов и преобразование там где надо. Но это уже изврат, однако. Особенно если надо всего пару фич объявить.
 А для написания основного кода надо использовать наследование, как и положено.
 ЗЫ: Сомнения дело хорошее. До тех пор, пока порождают конструктивные диалоги а не флуд и прочие холивары

@@ Строка 34: / Строка 34: @@
 ЗЗЫ С виду язык в целом приличный (видел и сильно хуже), а вот вся остальная система вызывает большие сомнения в работоспособности при попытке запустить ее в большой сети.
 Использован будет последний, то есть последний перекрывает всех предыдущих. И действовать будут естественно в рамках модуля, объявившего данное расширение и всех модулях, которые его используют. Видать примеры в книге корявые, надо придумать что нибудь более реальное.
@@ Строка 40: / Строка 42: @@
 А для написания основного кода надо использовать наследование, как и положено.

← Предыдущая		Версия 12:42, 25 апреля 2008
Строка 34:		Строка 34:

	ЗЗЫ С виду язык в целом приличный (видел и сильно хуже), а вот вся остальная система вызывает большие сомнения в работоспособности при попытке запустить ее в большой сети.		ЗЗЫ С виду язык в целом приличный (видел и сильно хуже), а вот вся остальная система вызывает большие сомнения в работоспособности при попытке запустить ее в большой сети.
		+
		+	Использован будет последний, то есть последний перекрывает всех предыдущих. И действовать будут естественно в рамках модуля, объявившего данное расширение и всех модулях, которые его используют. Видать примеры в книге корявые, надо придумать что нибудь более реальное.
		+
		+	В целом, расширения не предназначены для написания фундаментального кода. Основная идея в том, чтобы можно было подкрутить класс "под себя", без необходимости перелопачивать код. Ориентировка на то, что тебе дали объект, но ты хочешь от него чего то еще. Если проводить аналогию с тем же Ruby. Тебе возвращают объект, но ты хочешь чтобы он умел производить с собой некоторые действия, скажем выводить некоторую информацию (инспектировать себя). И эту информацию ты используешь в своем коде. Тогда просто создается расширение в котором объявляется необходимый метод. Притом что оно никоим образом не мешает другим пользователям (которые так же могут у себя делать расширения). Альтернатива этому подходу -- написание врапперов и преобразование там где надо. Но это уже изврат, однако. Особенно если надо всего пару фич объявить.
		+
		+	А для написания основного кода надо использовать наследование, как и положено.