My thoughts about FreeBasic and "Object Oriented code&a

HD_ · Post by **HD_** » Sep 30, 2008 1:29

Well I think a cross platform FB GUI should be left for third party libs, rather than be included as a core feature of FB.

I feel worried to hear any kind of suggestion that there should be OO-only FB features when currently OO tends to perform slower :( What kinds of things does every suggest should be converted to OO? Include sample code please.

I will agree that atm, the FB name space is absolutely polluted with words that I often want to use as variables (dir, pos, name, len, etc.), so I would be happy to see those wrapped up and hidden behind name spaces or objects.

agamemnus · Post by **agamemnus** » Sep 30, 2008 20:48

HD_ wrote: I will agree that atm, the FB name space is absolutely polluted with words that I often want to use as variables (dir, pos, name, len, etc.), so I would be happy to see those wrapped up and hidden behind name spaces or objects.

That's what makes it easy. You can't take that away unless you undefine those.

angros47 · Post by **angros47** » Sep 30, 2008 21:11

I don't think that FB will ever become a 100% OOP, with no more support for functional programming: if commands like dir, pos, len were wrapped into object, FB itself will be no more self-compiling.

Havng more dialects doesn't mean forking (by now it's even possible to mix modules made with different dialects, using $lang), and was the only way to implement new features and keep retro-compatibility with QB (lots of programmers start using FB because they want to port their old code on windows/linux)

While FB implements more features, it becomes closer to C/C++: i like the new scoping rules, but hate having to declare every variable or function type; it makes the code a lot verbose, and difficult to be read:

Code: Select all

print Variable;

What is Variable? Is it a string? or an integer? I have to check all the code, until i find DIM Variable AS ...
While with the old syntax

Code: Select all

PRINT Variable$

It's intuitive, Variable is a string.

And try finding the error in expressions like:

Code: Select all

A=sqr(first^2+second^2)
B=sqr(third^2+forth^2)
C=sqr(A^2+B^2)

if by chance you DIMmed A, or B, or C as INTEGER....

So I'd like an environment without theese restrictions: FbLite doesn't have them, but it doesn't even have OOP.
Isn't there a way to have OOP (or, at least, a part of it) and OPTION IMPLICIT?

About OOP library: actually, there is no big difference having it integrated in the compiler or not: fbgfx had to be integrated, because it uses a "strange" syntax (PLOT and LINE need to have some args between parentesis, and LINE is used with INPUT, too)
There already are other libraries (mainly, FBSOUND) that IMO should become part of the language (having PLAY and SOUND on a multiplatform language could be very useful), but, really, the only difference will be that, instead of using an INCLUDE in your code, you enable/disable them with a compiler switch.

notthecheatr · Post by **notthecheatr** » Sep 30, 2008 21:39

Actually, nobody is planning to wrap those things in an object, merely to put them inside a namespace. That means they can still be used (and in a -lang qb mode the "Using FB" would be implicit) but they can be accessed from inside the namespace in case a person would prefer to name their variables by those names. And no, FB will never become pure OOP (like, for example, Java) - more like C++, where OOP is a feature but not the only way to do things. As noted earlier, sometimes OOP is handy but it's not the be-all and end-all to every solution you'll ever encounter, and it shouldn't be treated as such. We use it when it's appropriate, just like everything else. Adding OOP to FreeBASIC shouldn't actually change a lot (programs written in the normal non-OOP paradigm should still be compilable, although slight syntax changes might require slight modifications as the compiler continues development) but for those of us who use it it will be great.

Usually variables are either declared at the beginning of the scope (meaning you don't have to look far to find them) or right where they're first used (meaning you don't have to look at all). If you try to jump into the middle of a program and figure out what it's doing, then no, you won't understand it. But if you read it sequentially as it's meant to be read, you'll be able to figure out what's going on without too much difficulty (assuming it's a well-written program with descriptive variable names, good indentation and all the rest).

Code: Select all

'No question:  this is a string variable
Print userName

'This is an integer variable.  No idea which one (byte, short, integer,
'or longint) but we do know it's an integer.
Print itemQuantity

Type suffixes are kind of ugly and what if I don't WANT to use a $ at the end of every string I create? Anyways, QBASIC had an option that shows that even with default types you can have problems: DEFxxx. That changed the default type, so now if the default type is string instead of int or single, then every variable name without a suffix is a string... and that's no longer intuitive, unless you were giving your variables descriptive names to begin with.

And yes, sometimes we need to make sure we use one type and NOT another. Solution: use the right types! But if we have a "default type" and we simply don't DIM our variables, we can run into problems too. If default type is INTEGER, then your code will be broken if you don't declare the variables. And by the way, floating point numbers are not without their problems as well. In some cases it's safer to store things as integer when accuracy is more important than precision (see, for example, http://www.cprogramming.com/tutorial/fl ... point.html for a short discussion on this topic). So making the default type floating point can cause problems too.

Really, I don't ever want my compiler to accept everything I tell it to at face value. There's too much room for error on my part, and the compiler can't fix human error (or even detect it, in some cases, such as whether I should be using an integer or floating point number in a particular case). I should be able to figure that out on my own, be smart enough to do it right or find and fix the bug if I don't, and still program efficiently and properly. In fact, I daresay I program far more efficiently in FreeBASIC than I ever did in QBASIC, because my compiler demands that I tell it about every variable I'm going to use, and I do. This makes my programs easier to read and understand, and it helps me understand better how my programs work (when I was using QBASIC, I didn't even know what the default type was - that's how ignorant you can become doing things that way).

I think OPTION IMPLICIT should be allowed in -lang qb, for one thing because of compatibility with QBASIC and for another because it's easier for newbies to learn to program that way. But there is absolutely no way in the world you're going to try to teach a newbie how to use OOP if they can't even declare their variables properly by now.

*whew* Got that out of my system.

Note: Just in case anyone thinks FreeBASIC is becoming "harder to learn," let me tell you that C/C++ is still a heck of a lot tougher than FreeBASIC and always will be. FreeBASIC you can use without including any libraries; C/C++ everything is in the runtime libraries, which are not implicitly included. You have to put a semi-colon at the end of most lines, but there are exceptions to that and you have to remember them. You have to remember the difference between = and ==, and if you use the wrong one your program screws up. I could go on. FreeBASIC is, and always will be, an easier and simpler language than C/C++. OOP support will not change that.

Lachie Dazdarian · Post by **Lachie Dazdarian** » Sep 30, 2008 21:42

If we need to change FB notably some more so it could support OOP, I really don't see a point in this anymore. What then are we being faithful to here, or nothing is holy in the FB syntax/code anymore? Where the original goals have gone? Do we want here only to keep the language name? Maybe GUI developers should consider a different language if to support OOP FB won't look like FB anymore.

notthecheatr · Post by **notthecheatr** » Sep 30, 2008 21:46

Though I'm not a developer, I think it's pretty safe to say this (I'm simply repeating what I said in my above post):

notthecheatr wrote:Adding OOP to FreeBASIC shouldn't actually change a lot (programs written in the normal non-OOP paradigm should still be compilable, although slight syntax changes might require slight modifications as the compiler continues development) but for those of us who use it it will be great.

May I remind you Lachie that the compiler has undergone significant changes since its creation, so that a program that compiled with the first version won't necessarily compile with the current version - that didn't cause the developers to start a new language, because the language wasn't finished yet. But other than the minor changes that come with every new version (and face it, there will always be slight changes - change happens in life, get used to it), OOP should not significantly change the syntax.

Lachie Dazdarian · Post by **Lachie Dazdarian** » Sep 30, 2008 21:58

I keep hearing "should" over and over.

"It should not change the syntax significantly..."

"Adding OOP to FreeBASIC shouldn't actually change a lot (programs written in the normal non-OOP paradigm should still be compliable..."

I just don't like the sound of this.

Maybe the time will show who was wrong here. Being a non-OOP coder, I just don't like feeling cornered by the future lang switches, dialect confusions and possibility of being ghettoized in one of them. It's all dirt to me. I don't like dirt.

Gimme a clean language who has a clear goal and agenda and is not trying to satisfy everyone. Make a decision. Slap in the face BASIC users or stay true to them. Simple as that.

anonymous1337 · Post by **anonymous1337** » Sep 30, 2008 21:58

Maybe GUI developers should consider a different language if to support OOP FB won't look like FB anymore.

It will look like FB. I don't see where other people are thinking differently. Just look at C++ compared to C.

angros47 · Post by **angros47** » Sep 30, 2008 22:21

RapidQ showed us that OOP and Basic syntax can cohexist, and work very well together: I hope that in FB it will be the same (and, if some choice are unavoidable, and some features have to be suppressed, at least that that will affect only one dialect)

notthecheatr · Post by **notthecheatr** » Sep 30, 2008 22:46

Ok, since Lachie doesn't look the word "should" I'll say "won't." OOP is an optional feature, just like a C program (which has no OOP at all) can compile in a C++ compiler in most cases with little or no modification at all. The differences are good things, and they're meant to be used, but if you don't WANT to use OOP you don't HAVE to. The OOP features do not change the way the language works.

I think I'll write an article on this topic for QBE, since it seems to be such a hot topic.

Nexinarus · Post by **Nexinarus** » Oct 01, 2008 2:21

Ah I am liking this discussion ;). Perhaps I should have worded my original post better, but what I wanted out of this is that we plan the changes before they happen, so that when(if?) they do happen everybody will be happy.

I think I am agreeing with most people here, that if it is implemented as an optional feature, where the run time libs are left the same, then it will be a seamless transition. However I do see an OO lib being created and being useful (for those who want it). For example, a lib for things like:
- linked lists
- vectors
- stacks
- trees

And probably other things. But this doesn't have to be a standard lib, could be an extra, like fbext.

Maybe we should discuss the syntax, for those who would appreciate having object support also. This is what victor wrote originally (from svn, todo.txt):

Code: Select all

== classes  -- single inheritance, plus interfaces -- Java/Php5-ish: CLASS EXTENDS IMPLEMENTS THROWS

Heres whats in the todo.txt now:

Code: Select all

== 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

notthecheatr · Post by **notthecheatr** » Oct 01, 2008 17:16

I wrote: OOP with OPTION IMPLICIT: Otherwise known as Magic. State of the art programming (hmm, FreeBASIC is now a ninth-generation programming language, meaning it reads your mind and figures out exactly what you want. Rah for FreeBASIC.)

Code: Select all

/' someObject is an object of the type someClass
 ' neither is actually declared or defined because we have
 ' option implicit doing all the magic for us!  Furthermore, x
 ' is an integer and something$ is a string - and the compiler
 ' is smart enough to figure that out because of the type suffix.
 ' Nice, isn't it?Also, q is a static double in someClass.  I'm
 ' not really sure how the compiler knows it's a double,
 ' but it works!  Heh heh.  Magic.  I think.
 '/

  someClass.q = 17.0

  someObject.x = 23
  someObject.something$ = "Hi, World!"

  Print someObject.x
  Print someObject.something$
  Print someObject.q

angros47 · Post by **angros47** » Oct 01, 2008 20:56

Of course classes and type members has to be declared (unless doing like in BlitzBasic, where there is no AS keyword and suffixes are mandatory even inside TYPES), but why having ALL symbols to be declared?
Why even in commands like FOR, or INPUT, the variable has to be declared, while 99% of the for-next use INTEGER and 99% of INPUT use STRING?
Also, if i have 99 integer functions, and one string function, why have I to write 198 "AS INTEGER" (one in the DECLARE FUNCTION, one in the FUNCTION), while i could use a "DEFINT A-Z" and only two "AS STRING"?
There should be a default type, and suffixes, even if somebody hates them, can be very useful shortcuts.
Nobody has to be "forced" to use implicit declarations, but why not being able to choose?

One reason why I don't like C/C++ or Java is that they're too verbose:

Code: Select all

public class HelloWorld {
     public static void main(String[] args) {
         System.out.println("Hello World");
     }
 }

It uses 10 keywords to do something that in basic needs only one command.
I don't want another similar language like this (and forcing to declare everything is the first step in that direction).

I'm sure many of you have already read this, but anyway I hope this will help to clarify my point of view:
http://www.ariel.com.au/jokes/The_Evolu ... ammer.html

Lachie Dazdarian · Post by **Lachie Dazdarian** » Oct 01, 2008 21:34

LOL

Awesome link. I'm bookmarking it.

Nexinarus · Post by **Nexinarus** » Oct 02, 2008 4:43

Well in my opinion, Id imagine classes would look almost identical to TYPE's, with a few extra capabilities.

Here's a type example, that works in the current freebasic release

Code: Select all

type HelloWorld
    Declare Constructor
    Declare sub Method1
    dim s as string = "hello again"
end type

Constructor HelloWorld
    print "Hello World"
end Constructor

sub HelloWorld.Method1
    print s
end sub

dim hw as HelloWorld
hw.Method1

'output:
'  Hello World
'  Hello again

I mean this has constructors, this has member functions, and the main thing that proper OO will add is inheritance and polymorphism, I guess?