While OO programming can be very useful for many things, it can also overcomplicate things to a seemingly endless point. I don't like OO, and I probably never will. Besides, OO code compiles to procedural code in the end, doesn't it? :wink:
Anyway, I guess the main point of this thread is to ask one question: if v1c implements OO into FreeBASIC, will it mess with or break any of the features that are already there (such as compatibility, pointers, etc.)?
All OOP breaks down to procedural code at some point in time. OOP is simply a convenience for more rapid development. I don't think v1c has any plans of breaking FB's procedural nature...as I've said before, doing that would effectively kill FB's backwards compatibility and in essence, kill FB itself because people would stop using it.
I'm agree with you adosorken. OOP shouldn't be the mainstream in FB. But rather it comes as an add-on for a group of users that need OOP features. In other words, FB has the basic elements that is supporting OOP implementations in FB coding. If user want to have object based add-on for their project, they could create their own set of include files with OOP styles or share among users that used to OOP.
With this way, all user didn't have to used if they didn't want to. Or they can mix a little OOP for specific case like Window GUI creations.
OOP is only bad if the programmer doesn't know how to use it... it can certainly be overdone or misused, but it can also improve code readability and, if used carefully, won't hurt performance at all. I think code readability is more important than performance in many cases anyway.
I may sound stupid now but:
Wouldn't it be possible to create sort of OOP preprocessor? That would take your oop code, convert it to procedural and then compile with FB?
I think that's what adosorken's POOP does.
I think that what V1ctor is doing is adding support for classes. That doesn't make the language OO, it just adds functionality, just like C++ evolved from C. C++ is weak in a way you can still code in C for a C++ compiler. If classes are added to fB, I think it will be just like that: if you want, you use object orientation.
Turning a language into OO means for example creating something like Java, C# or VB.NET, where you can only code OO programs and use classes and objects. Adding support for classes is more in the C -> C++ fashion (although C++ has more than just that, it is in fact a procedural language that can perform OO stuff, it is not a pure OO language at all).
Turning fB into OO would kill it. If you want to code in OO BASIC, try the .NET compiler which is free.
Quote:I may sound stupid now but:
Wouldn't it be possible to create sort of OOP preprocessor? That would take your oop code, convert it to procedural and then compile with FB?
Yes it's possible. Infact, it is what all the compiler do. The compiler read the OOP statements and convert it into procedural front-end language like asm or else. OOP is just like UDT except it has additional methods, events and constructors. For methods is just a sub/function that embedded into UDT just like embedding UNION or UDTs but in form of sub-routine or function.
While for events is a variables that store user's procedure pointer and execute them when the particular event occured. Mostly events used in GUI to do specific user's routines for the object.
Constructors is a default values or pre-defined execution/initialization set by the object writers. When a user DIM an object, the object Contructor will be execute to change values in it properties or run specific methods.
Adding classes does not make a language OO as nath said. It only makes it cpable of an Object based design.
What does "adding classes" mean? UDTs with methods? Than it's realy not object oriented but object based (
http://en.wikipedia.org/wiki/Object-based ).
If we get inheritance and polymorphism it is an object oriented language as it's capable of everything needed to do so. It's not a pure oo language, though, which is good IMHO.
BTW, constructors aren't neccessary for oo. Objective-C for example doesn't have them, but is very oo.
So perhaps V1ctor could be so nice and tell us what we'll get?
No kind of inheritance, single inheritance, single inheritance + interfaces or perhaps even multiple inheritance?
And what about encapsulation?