Page 4 of 4
Posted: Mon Jun 05, 2006 11:47 pm
by 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.
Posted: Tue Jun 06, 2006 2:00 pm
by dracflamloc
Mike Stefanik wrote: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.
Posted: Tue Jun 06, 2006 6:41 pm
by 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.
Posted: Wed Jun 07, 2006 3:49 pm
by 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...
Posted: Wed Jun 07, 2006 6:58 pm
by 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.
Posted: Wed Jun 07, 2006 9:50 pm
by mp303
utopiomania wrote: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.
Posted: Wed Jun 07, 2006 9:53 pm
by 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.
Posted: Thu Jun 08, 2006 9:46 pm
by fsw
How should ProcedureReturn Types in Classes be specified
Code: Select all
Class NotYours
Text.s
GetText().s
EndClass
This way
Posted: Thu Jun 08, 2006 9:58 pm
by 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
Posted: Thu Jun 08, 2006 10:19 pm
by fsw
inc. wrote: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...)
Posted: Thu Jun 08, 2006 11:34 pm
by inc.
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()
Posted: Fri Jun 09, 2006 2:54 am
by fsw
inc. wrote:
Both ways seem very PB uncommon.
Thats true. Thats why I'm asking for ideas.
inc. wrote:
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.
inc. wrote:
"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:
Posted: Fri Jun 09, 2006 8:19 pm
by fsw
Settled for:
because users are used to it while using arrays.
And it's working great so far
Posted: Tue Jun 13, 2006 2:57 pm
by mp303
dracflamloc wrote: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.
Posted: Wed Jun 14, 2006 9:45 pm
by 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: