Language Extension Through Preprocessing
Hmm.. nice work. :)v1ctor wrote:I added some support for inheritance. The changes are in the v0_22-inheritance branch.
work:Code: Select all
type TObject public: declare sub thing() private: dim as byte unused end type sub TObject.thing() print "TObject.thing()" end sub type TBase extends TObject public: declare constructor(value as integer) public: declare sub thing() protected: dim as integer value end type constructor TBase (value as integer) this.value = value end constructor sub TBase.thing() print " TBase.thing()" end sub type TDerived extends TBase public: declare constructor (value as integer) declare sub thing(value as integer) end type
Can we use moar BASICish language? "extends" sounds very dull.
Some ideas:
"DerivedFrom TBase" <-- my favorite.
"Using TBase"
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Here is the info from TODO.txt in the SVN about OOP. This is a very old file. It has been there for years:agamemnus wrote: Hmm.. nice work. :)
Can we use moar BASICish language? "extends" sounds very dull.
Some ideas:
"DerivedFrom TBase" <-- my favorite.
"Using TBase"
EXTENDS is what was planned long ago. I doubt it is going to change.[ ] 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
nice work v1ct0r. Thumb up!
I was wondering that perhaps while you are here and before you disappear into the wild again - please document and restructure the source so it would be easier for other people to get their heads around and help out? For example document describing the general compiler flow and internal logic, comments in the files what they do and what the main functions are, in what context they are invoked... Some header files are humongous and navigating / making sense of them is a problem...
And any hope for osx support? Or what would need to be done to compile on osx? I might have a go if I knew where to start...
I was wondering that perhaps while you are here and before you disappear into the wild again - please document and restructure the source so it would be easier for other people to get their heads around and help out? For example document describing the general compiler flow and internal logic, comments in the files what they do and what the main functions are, in what context they are invoked... Some header files are humongous and navigating / making sense of them is a problem...
And any hope for osx support? Or what would need to be done to compile on osx? I might have a go if I knew where to start...
I don't like Java, its abstract syntax, and the IDE/compilation issues... :-|D.J.Peters wrote:agamemnus@ if FB goes JAVA why new words for working things :-)
Just because v1ctor posted it there long ago doesn't mean there's no latitude for change.Imortis wrote: Here is the info from TODO.txt in the SVN about OOP. This is a very old file. It has been there for years:
...
EXTENDS is what was planned long ago. I doubt it is going to change.
v1ctor wrote:The other alternative would be "inherits" as in vb.net. The other keywords are pretty much standard and are the choice of most OO languages (abstract, interface, class etc).
I'm only adding support for inheritance right now. Polymorphism should be added later.
I think it should be "inherits", then, for three reasons:
1) I don't like the sound of "extends". (Sounds too much like a viagra ripoff!!)
2) Closer to a BASIC language (VB.NET as you said); "inherits" is less abstract-sounding. Very important.
3) Will someone who already extensively uses and likes C++ or Java use FreeBasic? Very likely not. From VB or another basic? Yes. It should be more familiar to them to make it more likely they will switch.
Well, I'm biassed of course, but if you recycle class, you can use parentheses:v1ctor wrote:The other alternative would be "inherits" as in vb.net. The other keywords are pretty much standard and are the choice of most OO languages (abstract, interface, class etc).
Descendant = class(parentclass)
or
Descendant = interface(parentinterface)
abstract and similar keywords (sealed, deprecated,platform,abstract) appear before class/interface kw.
VonGodric: Sup, mate? Hmm, I doubt the sources will ever be well documented. I don't have much time to work on the missing features, let alone writting docs, really sorry.
If nobody is against "inherits", it could be that, no problem. But I find it easier to remember "extends" than "inherits". Probably because in my tongue, "inherits" is written as "herda", while "extends" is "estende" (stupid Portuguese, the noun has a "x" while the verb is written with a "s").
marcov: that's too Pascal-ish :)
If nobody is against "inherits", it could be that, no problem. But I find it easier to remember "extends" than "inherits". Probably because in my tongue, "inherits" is written as "herda", while "extends" is "estende" (stupid Portuguese, the noun has a "x" while the verb is written with a "s").
marcov: that's too Pascal-ish :)
IMO the 'extents'/'inherits' question should be seen from a practice point of view. Which one makes it easier to translate code from the most used other languages (C/C++ ATM).
When FB can support all C/C++ features in an UDT it makes sense to have the same keyword. When an FB UDT has to get reviewed after the translation it makes sense to use another keyword.
When FB can support all C/C++ features in an UDT it makes sense to have the same keyword. When an FB UDT has to get reviewed after the translation it makes sense to use another keyword.
Something can never be too Pascal-ish. :)v1ctor wrote:
marcov: that's too Pascal-ish :)
Anyway, the point was more that you don't necessarily need a new keyword, but can use a fixed position after a keyword that already signals a class declaration.
You are probably aware of it, but for the benefit of the forum: you'll also need kws or syntax too for what is "super" in Java, to select between a method in the current class and the parent. Without argument the methodname is the same as the current one. And of course a method might not be implemented in the direct ancestor, but it might also be in one ancestor beyond.