объектная надстройка над freebasic

Я вчера думал над тем, как из freebasic сделать более гибкий язык. В первую очередь речь идёт об объектноориентированности, ну и динамических переменных.

И вот какая мысля появилась. К сожалению, она пока ещё не оформилась, как следует.

Начнём с того, что и почему надо улучшать.

1. классы не наследуються.
2. объекты не передаються.
Что собственно делает язык уже не объектноорентированным, а только основанным на классах (как я тут недавно узнал).

Теперь динамические переменные. На самом деле это конечно изврат. Но я думаю, что он мог бы в некоторых случаях быть полезным.

Ну и наконец, усложнённый синтаксис связанный со всеми модернизациями.


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

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

И так, динамические переменные. Я думаю, те кто писал на JavaScript или php это знают. И знают их преимущества. На самом деле речь больше идёт не о динамических переменных, а о массивах. Ну да ладно, буду проще.
Мы просто вводим новые функции.
SetVar( {varname}, {value} )
{value} = GetVar( {varname} )
UnSetVar( {varname} )
IsVar( {varname} )
Назначение думаю понятно по названию.
varname имя переменной
value - значение переменной

Но вот если такое просто сделать, со списками. Кстати, я же кидал линк на мою библиотечку ini.dll, там нечто похожее. То сделать массивы уже сложнее. А главная сложность уже в том, как реализовать это удобным образом.
Логично было бы сделать как в php
a1 = new array
a1["first"] = "первый"
a2["second"] = "второй"
И пусть будут круглые скобки, это можно пережить.
Но тут ещё одна проблема, это несколько индексов.
a1["first"][1] = "вложенный"
И как такое написать на basic?

Можно конечно разбивать строчку знаками
SetVar("first/1", "вложенный")
Но это же лишнее время для разбора.


Ладно, динамические переменные, это не то. А вот объекты. Это уже действительно проблема. Я даже и не знаю, как разрулить.

Сейчас вижу два решения. Причём они потребуют, уже внедряться в компилятор. Или писать обработчик исходников, чтобы привести к нужному.

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

Примерно так:

set myobj = class1
myobj.method1(, 2, 3)
unset myobj

Это в стиле visual basic. Но внутри, после прохода обработчика будет жуть.

Вот я и думаю, стоит ли этим заниматься?
Могу ещё много написать, но думаю, лучше будет показать уже рабочую версию.

Зачем это все нужно? Ведь все это в планах у разработчиков компилятора.
Вот отрывок из TODO:

classes
- *MUST* follow the GCC 3.x ABI to make it easier to reuse C++ libs compiled by GCC
- Java/Php5-ish syntax: CLASS INTERFACE EXTENDS IMPLEMENTS THROWS ABSTRACT
- must support forward references for any kind of symbol, so classes can't be stored
directly to AST
- how to deal with "foo(expr)"? it could be an array or a function call..
- keeping everything in a parser/token tree will allow templates to be added later
- class shouldn't be emitted unless referenced
- function bodies defined outside classes follow the private/public proc rules
- single inheritance, plus interfaces
- exceptions - with stack unwind support
- pure virtual methods
- down casting
- some support for RTTI

Предполагается сделать вполне объектно-ориентированный язык программирования. Правда не известно когда это будет реализовано

Это же отлично. Но я об этих планах узнал впервые. Что с меня взять?
Значит буду ждать. Надеюсь не очень долго.

Наконец я хоть подумал, как это должно в принципе выглядеть. Весьма познавательно.

Согласен! ФриБейсик мне нравится как язык . Единственное, чего в нем не хватает - так это наследования (хотя можно и без него, но тогда ради чего все придумывалось?) и небольшой оптимизации исполняемого кода (точнее - не исполняемого, а ассемблерного, из которого делается исполняемый файл, т. к. там в некоторых местах можно было-бы и сократить число однотипных операций типа mov eax,0 ). А теперь - чисто мое субъективное мнение (может быть и не совсем правильное): было-бы неплохо перевести ФриБейсик из ГАСа в НАСМ - код был-бы очень компактным . Но, видимо, выбор обусловлен тем, что Авторы (хвала им ) знают лучше всего и тем, что оттестировано и проверено временем. Хотя, при всей небольшой неоптимизированности выходного кода, работают программы шустренько и даже очень. Куда там крутейшим компиляторам от Майкрософта с их крутейшей оптимизацией ... Куды нам сирым... (че-то понесло меня

Кстати, вопрос не в тему: а никто не знает, почему в ПХП наследование называется расширением?

было-бы неплохо перевести ФриБейсик из ГАСа в НАСМ

И в результате получить кучу проблем с линковкой и переносимостью? Все-таки gas входит в gcc, и поэтому у него есть хотя бы какая-то гарантия развития, в отличие от практически забивших на свое творение авторов NASM. Ошибкой разрабов ФБ было то, что они стали делать эмиттер на ассемблер, нужно было выбирать один из уже готовых генераторов кода (ну хотя бы вроде того же llvm - намного проще в использовании, чем генерация асма, плюс получаем переносимость на кучу аппаратных платформ и нехилую оптимизацию). Тем более, что эмиттер уже переписывали и существует альтернативный способ генерации кода в С (это включается опцией компилера -gen gcc. С переносимостью-то вроде получается разобрались, а вот о качестве генерируемого С-кода... промолчу, потому что не углублялся в это.

Тут такое дело. FreeBASIC строился на базе MinGW. А значит получаем GAsm именно от него.
К сожалению сам MinGW не очень-то оптимизирован. Ребята портировали GCC внеся свои доработки, и главное у них в задаче было, чтобы этот чисто юниксовый компилер, хотябы как-то работал под форточками.
Я не знаю, что можно ещё сказать. Я не вкурсе планов разработчиков.

Транслировать в C это будет не верно. Всё же, сам FreeBASIC чуточку ближе к C++, чем к C. А значит транслировать надо в C++. Хотя правильнее, делать свой транслятор в ассемблер.
В GCC C++ транслируеться в ассемблер, что даёт возможность более качественно оптимизировать объектно-ориентированный код и добавить, более корректную информацию для отладки.
Ниже, я расскажу об особенастях компиляции с наследованием.

Очень жаль, что во фрибэйсике нет наследования. Именно по этому я и создал данную тему.
Была мысля, а теперь их даже две, как расширить FreeBASIC.

И так, во-первых это добавление наследования классов, виртуальные методы и прочие примочки.
Как было сказано выше, это всё в планах.
В мануале мы можем даже найти слово protected, оно именно для наследования и зарезервировано.
Есть там и слово class, о синтаксисе данной конструкции, мы уже говорили, на сём форуме. Хотелось бы, чтобы это было как в visual basic или vbscript.

А ещё хотелось бы поиметь события. Типа как во objective C. Чтобы были конструкции, вроде методов, но вместо слова function слово event и можно было бы кидать объекту события...
Но это значительно сложнее реализовать. Скорость будет тоже не очень высокой (в прочем всё зависит от способа реализации), но зато куча удобств!

Вообще-то мне хотелось, чтобы классы были динамическими. А типы type ... end type остались статическими.
Это даст большую гибкость. Особенно для взаимодействия между динамическими библиотеками.
Кстати это стоит обсудить отдельно.

А ведь во фрибэйсике есть ещё несколько слабых мест.
Например очень нехватает шаблонов template, это во истину огромное поле для кодеров. Тем более можно не ограничиваться подобием шаблонов из C++, а навернуть их ещё круче. Чтобы к примеру обрабатывать простым способом условия...


Приведение типов... Ну... С одной стороны мягкость, по отношению к не очень корректному коду, это облегчение для новичков.
Но сдругой стороны это потенциальный источник ошибок.
И лично я считаю, что приведение типов надо ужесточить!

Кстати, с приведением... Ведь тут ещё и метоморфизм... Так, что, надо ужесточать! Ну и соответственно добавить функций, которые будут разрешать.

Для классов, нужны ещё друзья friend.


Да и нет таких понятий как volatile, mutable, explicit... Есть const, но я бы ещё добавил dinamic, в противоположность ему.



Терминология была проблемой уже давно.
В разных языках одно слово означает разные понятия.
А в других одно и тоже понятие, называют по разному.

Например в C++ есть конструктор копирования, а в php есть конструктор клонирования.

Да и с классами не всё так просто. Ведь в php динамический класс, а в C++ статический.
И если честно, то в C++ это правильнее называть типом, а не классом. В прочим они уже привыкли.

А понятие наследования... Ха-эм. На самом деле всё ещё сложнее.

интерпретаторы и Компиляторы действуют очень по разному.

Например когда наследуеться класс в C++, то просто происходит наложение.
На фрибэйсике это раскрытие выглядело бы так:

Код:


' код базового класса
type class_base
declare sub method1()

field1 as integer
end type

sub class_base.method1()
...
end sub


' код дочернего класса
type child_class
extended public class_base

declare sub method2()

field2 as integer
end type


sub class_child.method1()
...
end sub


Компилятор когда создаёт объект некого класса имеет табличку его методов. И он знает, по какому адресу лежит тот или иной метод.

Фактически метод вызываеться так:

Код:


push obj_ptr
call class_base.method1
end asm


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

Код:


type child_class

declare sub method1  alias class_base.method1 ()
declare sub method2()

field1 as integer
field2 as integer
end type


Прошу прощения если с alias напутал, я его не юзал.
Имелось в виду, что
Объявить метод method1, но использовать код по адресу class_base.method1

С полями всё не совсем так просто, ведь компилятор использует смещение от начала объекта. И тут порядок расчитываеться по хитрому и есть ещё область видимости...


Ну вот, а как это правильно всё назвать?

С одной стороны "расширение класса". В смысле берёться базовый класс и его возможности расширяються.
Стоит заметить, что в php можно наследовать только один класс!

А в C++ можно наследовать несколько классов.
И наверное термин "наследования" подходит больше.

От родительского класса берёться нужное. В ребёнке (дочернем классе) соеденяються свойства и возможности нескольких предков, но к этому добавляеться ещё что-то новое.

Так что о терминах сложно судить, тем более не англоязычным товарищам.

Уф. Чего-то мне надоело.
Хотел ещё рассказать о виртуальных методах и динамических классах.
Ну да ладно, как нибудь в следующий раз, если оно будет интересно.

Наследование было-бы не проблематично реализовать, если бы был хоть какой-то способ доступа к полям в структурах - именно к их названиям и типам (а не обращения к полям как обычно). Вот если бы можно было перебрать все содержимое ОПИСАНИЯ структуры - тогда бы и наследование было легче организовать (хотя бы в виде макроса).


Теперь по поводу

И в результате получить кучу проблем с линковкой и переносимостью?

(от DiG. GeRR): у НАСМа проблем с линковкой нет (по крайней мере я не встречался с этим). Хотя больших проектов не пробовал на нем писать (недавно только занялся) Но первые попытки переписать на нем некоторые ранее писанные на МАСМе вещи проблем не вызывают. Компиляция - в -fwin32 а линковка МАСМовским линкером пролблем не вызывает... Хотя, повторюсь, ПОКА... Тут, похоже, главное - объявить все используемые АПИ и отдать линкеру все либы. Вот и все (вроде).
Хотя у НАСМа есть одна нехорошая черта: скомпилированная на АМД-процессоре программа будет немного медленнее работать на Интеловском процессоре. Я с этим столкнулся, когда меня попросили сделать сортировку входных (на СТДИН) данных на ассемблере методом поиска минимального элемента. Так вот, на машине с АМД-процессорами (на Атлоне пример компилировался и линковался) сортировка 10000 элементов проходит в районе 200-215 мс., а на ИНТЕЛовском процессоре - 315-320 мс. В чем загвоздка - видимо в привязанности к платформе и, как следствие - не очень-то и переносимости.

Во freebasic, можно хоть сейчас сделать подобие виртуальных методов.
Они отличаються от обычных, тем, что указатели на них храняться в объекте.

так вот, вместо объявления функции, объявляем указатель на неё.

Код:


type someclass
dim method1 as sub ptr
...
end type


Дальше, где-то в конструкторе, указателю виртуального метода присваиваеться значение указывающее соответствующей функции.
Но вот с доступом к полям... Ха-эм... Тут будут проблемы!
Так что по любому, либо kлесть в ядро компилера, либо извращаться над самим кодом, спецальной утилиткой, которая приведёт его из объектно-ориентированного формата, в просто объектный.