Мощная среда ZXDev для разработки НА ПЯТИ ЯЗЫКАХ для ZX готова к тестированию

[Eltaron]

И с чего сделан такой вывод?

Придумай хоть одно практическое применение тому наследованию, которое описано Абстрактные классы, виртуальные функции - ничего же таким образом не реализовать. А там, где реализовать, там аггрегированный родительский элемент в принципе не нужен, достаточно статического метода (глобальной функции). Тут какая-то подмена наследования mixin-ами, кмк.

[Advertiser]

[Vitamin]

Придумай хоть одно практическое применение тому наследованию, которое описано

Аффтар всего лишь рассуждает, можно ли полностью отказаться от наследования имплементации в пользу агрегирования (имхо, можно и даже нужно! И да, читай замечания).

Абстрактные классы, виртуальные функции - ничего же таким образом не реализовать

Мысли шире. Назови наследование от абстрактного интерфейса имплементацией (ибо де-факто ничего, кроме описательной части не наследуется) и вполне сможешь избавиться.

А там, где реализовать, там аггрегированный родительский элемент в принципе не нужен, достаточно статического метода (глобальной функции).

Пример дашь?

[Eltaron]

Пример дашь?

Навскидку

public Base
{
	virtual int GetSomething1() = 0;
	virtual int GetSomething2() = 0;
	virtual int GetSomething3() = 0;
	virtual int GetSomething4() = 0;

	void DoJob() { print((GetSomething1()+GetSomething2()+GetSomething3()+GetSomething4())  * 57.2418); }
}

public Child : Base
{
	int GetSomething1() { return 90; }
	int GetSomething2() { return 5; }
	int GetSomething3() { return 17; }
	int GetSomething4() { return 9; }
}

переписывается в идеологии статьи как

typedef int (*get_something)();

public Base
{
	void DoJob(get_something param1, get_something param2, get_something param3, get_something param4) 
	{
		print((param1() + param2() + param3() + param4()) * 57.2418); 
	}
}

public Child
{
	Base* base;
	Child(Base* base) { this.base = base; }

	void DoJob() { base->DoJob(GetSomething1, GetSomething2, GetSomething3, GetSomething4) };
	int GetSomething1() { return 90; }
	int GetSomething2() { return 5; }
	int GetSomething3() { return 17; }
	int GetSomething4() { return 9; }
}

Я, наверное, слишком привередлив, но мне кажется, что это хрень какая-то. Если бы я хотел передавать в функцию указатель на каждую требующуюся ей функцию, я бы писал на хаскелле. И это ещё методы примитивные, с 0 параметров! Даже на си с его полиморфизмом через структуры указателей это всё было бы в разы лаконичней.
Потому статья и тянет скорее на теоретические измышления, чем на практическую ценность.

[Vitamin]

переписывается в идеологии статьи как

Нет. Посмотри внимательнее, чем отличаются просто функции (глобальные) и методы класса (не важно, виртуальные или нет).

[Andrew771]

Олег, за весь мир не скажу, но конкретно по этому сообществу - в основном тут люди, ностальгирующие детскими увлечениями. Вот было многое на ZX помимо ассемблера и бэйсика - и C, и паскаль, и форт, и лого, и всякие высокоурвневые редакторы... Но вот Оберона не было ну совсем. Не аутентично оно как-то. Это основная причина непопулярности Оберона здесь. Кстати, как и прочих JScript'ов, кросс-паскалей и даже новомодных фишек АТМ'а (его SDK, например). Остальное вторично.

Неа. Hisoft Паскаль и ассемблер (Gens) фиговаты, не удобны. Особенно бесит нумерация строк. На их Паскале серьезного ничего не напишешь. Поэтому пишем свои компиляторы.

[Alex Rider]

Hisoft Паскаль и ассемблер (Gens) фиговаты, не удобны.

Не знаю как обстоит дело с Паскалем для Z80, а у GENS'а есть достаточно удобных последователей. Да и в любом случае, компилятор Паскаля для Z80 я понимаю, сам даже баловался. А вот компилятор C# для Z80 не пойму.
PS Вернее, не так. Компилятор с C# для Z80 не поймут именно тут.

[b2m]

И с чего сделан такой вывод?

Да хотя бы его идея "а давайте сведём наследование к пролиморфизму", теоретически можно (что он в статье и показал), а вот практической пользы от этого - ноль, потому что писать много лишнего придётся.

ООП вообще - не более чем удобство записи. Всё можно и на обычном С реализовать, но писать больше придётся: вместо интерфейса - указатель на структуру с двумя указателями (данные и таблица виртуальных функций), вместо наследования - агрегация родительской структуры в структуре наследника, вместо инкапсуляции - просто соглашение "не трогай это".

[Vitamin]

Да хотя бы его идея "а давайте сведём наследование к пролиморфизму", теоретически можно (что он в статье и показал), а вот практической пользы от этого - ноль, потому что писать много лишнего придётся.

Ну конечно. Лучше лишнего написать, чем лишний раз подумать.

ООП вообще - не более чем удобство записи.

ООП- это смена парадигмы с "есть данные, а есть функции для их обработки" на "есть объекты, отражающие предметную область и состоящие из данных и поведения". И пока не осознаешь этого, так и будешь писать "брутальный *****код, представляющий собой кровавый замес из процедурного C, недообъектного и недотипизированного C++" (С)

[Q-Master]

Аффтар всего лишь рассуждает, можно ли полностью отказаться от наследования имплементации в пользу агрегирования (имхо, можно и даже нужно! И да, читай замечания).

Хех. Судя по твоим словам, аффтар открыл делегаты - основную парадигму яблопрограммирования на objc.

[b2m]

Лучше лишнего написать, чем лишний раз подумать.

Я так не говорил. Лучше вдумчиво писать, чем постоянно думать о том, как можно было бы написать. У лентяя всегда инструменты виноваты.

ООП- это смена парадигмы с "есть данные, а есть функции для их обработки" на "есть объекты, отражающие предметную область и состоящие из данных и поведения".

Данные и поведение было и до придумывания ООП. А объектами лучше называть реально существующие вещи.

И пока не осознаешь этого, так и будешь писать "брутальный *****код, представляющий собой кровавый замес из процедурного C, недообъектного и недотипизированного C++" (С)

В том, что программы с ошибками пишутся, чаще всего виноваты люди, а не парадигмы.