OOP Syntax

[Fred]

Actually the Windows API tries to have many functionality per function to have less exported functions as possible. The example of the window.show() is correct, but that means than you will have many more accessors (window.move(), window.changezorder() etc...) for this API function. I believe it's a deliberate choice from microsoft because they could have do ChangeWindowZOrder() MoveWindow(), ShowWindow() (huh, these last two sounds familiar ) etc. to ease the programming. But it would have bloat the shared core dll which is probably not acceptable.

Now, MS moves more and more to object oriented DLL (based on COM like DirectX etc.) to solve this.

There is also a naming space problem when dealing with procedural programming. With OOP you can use the 'show' method in many different object, even if there is not a single class in common. Within an OS, using procedural approach result in naming problem: look at the WinAPI, sometimes the 'object' name is prefixed (HeapAlloc(), HeapFree() etc.) sometimes not (ShowWindow(), EnableWindow() etc.).

As Mike said, the big advantage of OOP is organization when dealing with big programs. It is easier to make many persons work on the same project as long you have defined the class content and what it should do. Then all class can be seen as individual blackboxes, which are self contained.

[dracflamloc]

The biggest resistance to OOP generally comes from one of two camps. The first are the folks who just don't understand it conceptually, so they don't see why it would be of any benefit. They tend to think of it as just another way to do functional programming. The other camp are the folks that understand it, but fall into the "old dog, new tricks" category -- what they know works for them, and they're just not interested in changing their programming style, habits and methodology.

I use C++ to program with objects all the time. But I still don't really think PB needs OO built-in. I think a preprocessor would be grand, even an officially supported one. But PB has always been a lightweight and quick-to-the-point language. I really would hate to see that changed. I have no problem with OO in general, just with OO in PB itself. Something that needs to be considered is whether garbage collection will be done automatically or if you will leave it manual like C++. One of the nice things about PB is that its easy for a beginner to learn yet advanced enough for a seasoned veteran to use in most cases. Added object memory to keep track of if you go the manual route will make it much harder for beginners and they might as well use C++. On the other hand using garbage collection makes compiled code much larger and less efficient.

There are plenty of other OO languages out there, one you may like is the D programming language. Its similar to java but compiles natively. It does still have garbage collection I believe.

That said, I really don't use PB for much anymore at least until v4 for linux is out. If someone makes an OO preprocessor I'd hope that they do it using native PB functions so it can be ported to the other 2 OSes.

[fsw]

How about that?

Code: Select all

; no parentesis means no constructor is executed
; Create NewObject myWindow.Window
; Create NewList myWindow.Window
; Create NewArray myWindow.Window

; parentesis means constructor is executed with the parameters
; you can, if you wish so, global it...
; variables are treated as a single object
; Create Global NewObject myWindow.Window(1,2)
; with Lists the first element is automatically added 
; Create Global NewList myWindow.Window(1,2)
; with Arrays the first element is automatically added 
; Create Global NewArray myWindow.Window(1,2)

This way different class objects can be created:
variables with the class as type
lists with the class as type
arrays with the class as type

The keyword CREATE signals the parser what to do...

Just a thought.

[mp303]

@Fred:

You don't sound at all opposed to OOP in general - it's relief to know that the person behind PB is not ignorant to the qualities of many modern programming languages.

Do you think it's possible, at some point in the future, that PB will have native OOP features added?

Or should we rely on doing a preprocessor of some sort?

From looking at PB in general, it's clear that you're an optimization genius of some sort - I'm not saying this to flatter you, but the PB libraries are incredibly compact and fast. Given your ability to optimize for size and speed like you do, I find it not at all unlikely that you could figure out how to add support for OOP without performance or filesizes suffering any real hit. If it's implemented in such a way as to not interfere with non-OOP programs - and by enabling OOP features with a compiler flag, even compiler time might not take a hit...

[utopiomania]

'I'm not saying this to flatter you...'

'Sucking up to' is a better description I guess. And you know what his post means, don't you? Some of Freds
competitors are planning OOP, so he probably have no choice.

[mp303]

Some of Freds competitors are planning OOP, so he probably have no choice.

Most of Fred's competitors have OOP, some have had it for years... if, at some point, Fred decides to add OOP features to PB, I'm pretty sure it'll be of his own free will. He has never seemed too concerned with what the competition have been doing in the past, either way.

[dracflamloc]

To implement OOP natively would be a large undertaking and I doubt that a one-man team (for the compiler) like fred would want to support and develop that.

[fsw]

How should ProcedureReturn Types in Classes be specified

Code: Select all

Class NotYours
  Text.s
  GetText().s
EndClass

This way

[inc.]

Imho in the declaration not needed ...
Like in the parser examples only in the definitons.

Code: Select all

Class NotYours
  Text.s
  GetText()
EndClass 


Procedure.s NotYours::GetTExt()
  ...
  ...
EndProcedure

[fsw]

Imho in the declaration not needed ...
Like in the parser examples only in the definitons.

Code: Select all

Class NotYours
  Text.s
  GetText()
EndClass 


Procedure.s NotYours::GetTExt()
  ...
  ...
EndProcedure

Well, if classes are done with datasection and the datasection are located where the class structure and interface is then they need to be declared before the datasection.


Maybe I do it that way:

Code: Select all

Class NotYours
  Text.s
  .s GetText() ; write return type only if not long
EndClass 

easier to parse, but somehow it looks weird.


(or I finally need to switch to remi's lexer...)

[inc.]

Code: Select all

.s GetText()
or
GetText().s

Both ways seem very PB uncommon.

Well, if classes are done with datasection and the datasection are located where the class structure and interface is then they need to be declared before the datasection.

Then get rid of datasections if that is a problem. Someone also pointed out that inheriting could be more complex as the datasection of the new class will still have to include the pointers to the methdos of the motherclass.

"Try" this (based on Hellhounds example) .... and Im shure the resulted code won't be that noticable longer than the datasection-approach

Code: Select all

;//////////////////// Class BASE ////////////////////
Interface IcBASE
    Print1()
    Print2(b.l)
EndInterface

Structure VTcBASE
    *Print1
    *Print2
EndStructure

Structure cBASE
    *VTable
    Var1.l
EndStructure

;//////////////////// Methods ////////////////////

Procedure cBASE_Print1(*THIS.cBASE)
    PrintN("Cool")
    *THIS\Var1 = 50
EndProcedure

Procedure cBASE_Print2(*THIS.cBASE,b.l)
    PrintN("Var1 is "+Str(*THIS\Var1))
    *THIS\Var1 = b
EndProcedure


;//////////////////// Constructor ////////////////////

Procedure.l CreateBase(c.l)
    ; //// Construction ////
    *VT.VTcBASE  = AllocateMemory(SizeOf(VTcBASE))
    *THIS.cBASE = AllocateMemory(SizeOf(cBASE))
    If Not (*VT Or *THIS) : ProcedureReturn #False : EndIf
    *VT\Print1 = @cBASE_Print1()
    *VT\Print2 = @cBASE_Print2()
    *THIS\VTable = *VT

    ; //// Example of Initialization options ////
    ; Assign a value to an attribute of the object
    *THIS\Var1 = c
    ; Get the pointer to the Methods of this object ...
    *mTHIS.IcBASE = *THIS
    ; ... and call a Method of this Object.
    *mTHIS\Print2(c*2)
    ProcedureReturn *THIS
EndProcedure



;//////////////////// Class OBJECT inherits BASE ////////////////////

Interface IcOBJECT Extends IcBASE
    print3()
EndInterface

Structure VTcOBJECT Extends VTcBASE
    *print3
EndStructure

Structure cOBJECT Extends cBASE
    String.s
EndStructure

;//////////////////// Methods ////////////////////

Procedure cOBJECT_Print2(*THIS.cOBJECT,b.l)
    PrintN("Overloaded :"+Str(b))
EndProcedure

Procedure cOBJECT_Print3(*THIS.cOBJECT)
    PrintN("This one is new." + *THIS\String)
    ; get the pointer to the Methods of this object ...
    *mTHIS.IcOBJECT = *THIS
    ; ... and call a Method of this Object.
    *mTHIS\Print2(400)
EndProcedure


;//////////////////// Constructor ////////////////////

Procedure CreateObject()
    ; //// Construction ////
    *THIS.cOBJECT = AllocateMemory(SizeOf(cOBJECT))
    *VT.VTcOBJECT = AllocateMemory(SizeOf(VTcOBJECT))
    If Not (*VT Or *THIS) : ProcedureReturn #False : EndIf
    *VT\Print2 = @cOBJECT_Print2()
    *VT\Print3 = @cOBJECT_Print3()
    *THIS\VTable = *VT

    ; //// Initialization ////
    ; Assign a value to an attribute of the object
    *THIS\String = "TEST"
    ProcedureReturn *THIS
EndProcedure





;//////////////////// Create the objects  ////////////////////

OpenConsole()
base.IcBASE = CreateBase(190)
If base
    base\Print1()
    base\Print2(400)
    Object.IcOBJECT = CreateObject()
    If Object
        Object\Print2(100)
        Object\print3()
        Delay(5000)
    EndIf 
EndIf 
CloseConsole()

[fsw]

Code: Select all

.s GetText()
or
GetText().s

Both ways seem very PB uncommon.

Thats true. Thats why I'm asking for ideas.

Well, if classes are done with datasection and the datasection are located where the class structure and interface is then they need to be declared before the datasection.

Then get rid of datasections if that is a problem. Someone also pointed out that inheriting could be more complex as the datasection of the new class will still have to include the pointers to the methdos of the motherclass.

This problem is already solved in the code I potsed in Tips&Tricks awhile ago.

"Try" this (based on Hellhounds example) .... and Im shure the resulted code won't be that noticable longer than the datasection-approach

But I like the DataSections more...

Have to sleep over it :roll:

[fsw]

Settled for:

Code: Select all

GetText.s()

because users are used to it while using arrays.
And it's working great so far

[mp303]

To implement OOP natively would be a large undertaking and I doubt that a one-man team (for the compiler) like fred would want to support and develop that.

It may have been a large undertaking, but he already did implement it - features to support OOP are already present.

Basically, all we're asking for, is a more readable syntax and perhaps some compile-time/run-time checking.

[utopiomania]

Guys, read up on pro/con's to OOP on the old internet. It's not as obvious as stated here. The right tool for the
job etc..

Basically, go somewhere else for OOP, use PB for everything else...

There's a risk they start breaking syntax, templates, source and everything else again if you get it your way, so
bad luck to you, mp303. :roll: