Свой компилятор(С++'о подобный)

[Kostia]

Еще хочу так:
//где-то далеко в инклудах
Class Integer{
...
};
//где-то у себя
Integer{/*БЕЗ НАСЛЕДОВАНИЯ :crazy:*/
//реализация своих методов
};
Т.е. иметь возможность расширять класс где угодно и когда угодно, без наследования. В общем одно и тоже если бы было можно так class Integer: public Integer{...};
И еще хочу так: Make("ТЗ.doc"); )))

[Пепел Феникса]

Ну в руби типа труъ ооп, есть тока методы, но метод можно написать не в классе, и он будет как бы методом главного класса, который является программой. :crazy:

норма.

Еще хочу так:

такое есть в Делфи(правда ограничено) и в шарпе.

В принципе, можно было бы [] перегрузить ^^

думаю будет, но может не в первой версии.

[anyx]

Сообщение от Kostia

//где-то далеко в инклудах

Современный ЯП, по-моему, должен использовать модули и import, а не include-файлы и препроцессор. Вообще препроцессор - зло, ибо делает код не читаемым. Если хочется рефлексии, то такие средства должны быть структурированы (смотрите, как в D сделано)

[Пепел Феникса]

Современный ЯП, по-моему, должен использовать модули и import, а не include-файлы и препроцессор.

да.

Вообще препроцессор - зло, ибо делает код не читаемым. Если хочется рефлексии, то такие средства должны быть структурированы (смотрите, как в D сделано)

инклюды думаю можно и оставить, но не как средство модульности.(хотя на практике, сворачивание кода, заменяет вынесение кода из файла лучше(чтоб файл поменьше текстом был))
вообще я думал что такое лучше делать на уровне проекта, а не на уровне кода.

[anyx]

Сообщение от Пепел Феникса

инклюды думаю можно и оставить, но не как средство модульности.(хотя на практике, сворачивание кода, заменяет вынесение кода из файла лучше(чтоб файл поменьше текстом был))
вообще я думал что такое лучше делать на уровне проекта, а не на уровне кода.

Можно сделать импорт структурированной заменой инклуду. Тогда имена модуля будут добавляться в текущее пространство имён.
Например, есть блок кода. В нём делается импорт модуля - и имена модуля доступны в блоке как локальные:

// main.lol

main() =
{
    import tools
    print(tools.mul(2, 3))
    print(tools.factorial(5))
}

// tools.lol

mul(a, b) = a * b

factorial(n) = fold(mul, range(n))

Естественно, множественный импорт одного модуля не даст нескольких копий его функций в бинарнике. Для линкера эти функции будут глобальными именами

[Сtrl]

Вот чего мне не нравится в C++ - постоянно надо указывать virtual. Неплохо бы директиву какую-нибудь, чтобы все методы и всё наследование было виртуальным по умолчанию.

[the_deer_one]

Сtrl

Неплохо бы директиву какую-нибудь, чтобы все методы и всё наследование было виртуальным по умолчанию.

Короче идеальный язык это руби. х_х

[Пепел Феникса]

Вот чего мне не нравится в C++ - постоянно надо указывать virtual. Неплохо бы директиву какую-нибудь, чтобы все методы и всё наследование было виртуальным по умолчанию.

да.

Можно сделать импорт структурированной заменой инклуду.

как в делфи uses.

[pu4koff]

Сообщение от Пепел Феникса

да.

И будет вопрос куда эту директиву совать, как себя поведёт код, когда он будет сборной солянкой из разных проектов,... Тогда уж пусть будет всё и всегда виртуальным, для избежания путаницы.

Сообщение от Пепел Феникса

как в делфи uses.

Чем оно принципиально отличается от инклюдов?
Тогда уж делать как в жабе/шарпе: подключать пространства имён, а не модули (читай конкретные файлы).

[rpy3uH]

Сообщение от pu4koff

Чем оно принципиально отличается от инклюдов?

тем что у них есть Initialization и Finalization секции, плюс ещё куча всяких мелочей и нюансов. очевидно, это в 10 раз удобнее, чем тупые инклуды. и в шарпе тоже кошерно сделано.