Page 7 of 8

Re: OOP Support (it is time)

Posted: Wed Mar 30, 2011 3:56 pm
by MachineCode
Shield wrote:Member definitions are nothing else than...bingo...code.
Okay, we are using the word "code" in two different contexts here. When I say "code", I mean the real program code that does the work (For/Next loops and such); not variable definitions or declarations and such. For that misunderstanding, I apologise.

Re: OOP Support (it is time)

Posted: Wed Mar 30, 2011 4:01 pm
by Shield
Alright. But as I mentioned, it's not important how the syntax is. :)
In C++ for example, usually you only declare functions inside the class {} block
and then you implement them outside of the class.

C# and Java on the other hand use the syntax you mean, in those languages,
function bodies ("executable code") are implemented directly inside the class definition.

Re: OOP Support (it is time)

Posted: Wed Mar 30, 2011 4:03 pm
by MachineCode
On this lighter note, I'm off to bed. Goodnight, Shield. :)

Re: OOP Support (it is time)

Posted: Wed Mar 30, 2011 4:04 pm
by TomS
Old users are also asking for it. Because it's really messy with the interfaces.
It just isn't fun to use it that way. Some guys from Germany are actually posting Classes (for games etc.) based on those interfaces. I think they have too much time :lol:
Debugging that sh*t without knowing exactly what you are doing is like hell, imho,
In PB without OOP-precompilers it should only be used for what it was intended for. Interacting with OOP-libraries.

>>In C++ for example, usually you only declare functions inside the class {} block

Well that sucks :lol:

Like I said, I like SimpleOOP because it's like the code I'm used to from PHP.

Code: Select all

Class myClass
    Public Method BlaBla()
        Debug "blabla"
    EndMethod
EndClass

Re: OOP Support (it is time)

Posted: Wed Mar 30, 2011 4:10 pm
by Shield
MachineCode wrote:On this lighter note, I'm off to bed. Goodnight, Shield. :)
Good night! :)

And I agree, it sucks to use interfaces for that purpose.
But it is the most readable way to go. You can ease up that process quite a bit though by using macros and other constructs.

I never tried SimpleOOP (as it wasn't out when I was using PB regularly).
So no comment on that tool. :) From what I saw and heard about it, it seems to be a handy application.

Re: OOP Support (it is time)

Posted: Wed Mar 30, 2011 10:00 pm
by luis
MachineCode wrote:So over this OOP discussion every few months. Can the team PLEASE put a stop to it once and for all, with an official word on yes/no ...
OCTOBER 2005

Q) Will the support of OOP in PureBasic be further extended/improved? Or will PureBasic be orientated rather at the procedural BASIC also in the future?

Fred replied:

A) No. It will stay a procedural BASIC, I don't plan to add class and such I think it will split the PB world in 2 classes (!): the one which have understood fully how OOP work and other which don't. Which means than you couldn't share source codes easily anymore at one place. Procedural and Object Oriented Programming are two opposite concepts and it's not a good idea to mix them in a BASIC language (which is intended for beginners...)


source: http://www.purearea.net/pb/english/interview.htm

Re: OOP Support (it is time)

Posted: Thu Mar 31, 2011 3:13 pm
by bembulak
A) No. It will stay a procedural BASIC, I don't plan to add class and such I think it will split the PB world in 2 classes (!) ... it's not a good idea to mix them in a BASIC language (which is intended for beginners...)
I really appreciate this statement and I already accepted Freds and Freaks point of view regarding any changes to PureBasic. Also, I don't thinks it's a good idea to have OO "glued on" afterwards. Either a language is OO when it's designed, or it is not. Pascal was never ment to be object oriented and the OO-Addon (called ObjectPascal) isn't really nice at all. It just doesn't feel right. It works, but it's not nice, there are still "atoms" (basic data types) and units just with functions/procedures. Falling back to procedural programming and having a bad mix at the end is quite easy.
So: if PureBasic is procedural, it is. Fine for me!

But I refuse to accept, that OO would split users into two different "tribes". If you learn OO right from the start it's an easy and natural thing. And, if a language has a good support for it , it's easy to learn it, even if you have long procedural experience.
Good examples IMHO are Python and Ruby. They all make heavy use of OO and it's so lightweight and easy. You don't have to struggle with lots of things, you just type and it works. I hardly think of all that stuff I have to care about in Java, when I use Python. No boilerplate code, no UML, just coding.
Sometimes I think Java really ruined the way, people think about OOP. If you have to use Java on a daily basis and need heavy and bloated IDEs and tons of documentation and all that stuff , you're a poor one!

Re: OOP Support (it is time)

Posted: Thu Mar 31, 2011 3:29 pm
by TomS
I don't think that he meant it would split the community into rival "tribes", that hate each other for using the one or the other way of programming.
It's just that some people would only use oop and have no clue about the procedural way of Purebasic, so those people can't help others anymore.
It's nothing new, people have their area of expertise and just don't look in the gaming forum, because they never created a game.
Same goes for the OS's
But with oop this effect is doubled.

Maybe this isn't the strongest point in the argument, but it's a point non the less.

But I think the "glued on" works pretty well with SimpleOOP and in PHP also, which was procedural only for the most time, but now supports oop somewhat (not all aspects of the philosophy are fully implemented, yet, I think, but it's quite usable).

Re: OOP Support (it is time)

Posted: Thu Mar 31, 2011 4:50 pm
by Zach
That still makes no sense.

I see code on here, that may not be really complex, but has all kinds of complex algorithms or math functions in it, which I know nothing about.
If I want to use it bad enough, or am just really interested.. I'll put in the time to do my best to learn something.

I mean... where do you draw the line in this context? I don't think OOP (or certain elements like simple classes which allow function definitions) as an option is so bad. And don't see how it will split the community in any way at all. Clearly some will know more about OOP than others; but then if they didn't want to spend time helping other people learn they wouldn't be here in the first place?

Re: OOP Support (it is time)

Posted: Fri Apr 01, 2011 9:28 pm
by utopiomania
and it's not a good idea to mix them in a BASIC language (which is intended for beginners...)
No need to mix them in the same BASIC language, you could market two basic dialects.

And, beginners today find OO languages to be much simpler to learn than procedural/event loop based programming languages like the current version of PB.

Re: OOP Support (it is time)

Posted: Fri Apr 01, 2011 11:20 pm
by MachineCode
utopiomania wrote:beginners today find OO languages to be much simpler to learn than procedural/event loop based programming
That's because today's kids are dumbasses. Case in point: http://www.youtube.com/watch?v=CD2LRROpph0

Re: OOP Support (it is time)

Posted: Fri Apr 15, 2011 1:45 pm
by Yogi Yang
Just recently I received an email which contains OOP related opinion of a Compiler Writer.

Here are a few extracts from it:
An object is a pre-defined set of data (variables), neatly packaged with a group of subroutines (code) which manipulate the data and provide any other functionality you need.

For example, a string array containing names and addresses (data) might be packaged with a subroutine (code) that displays a popup dialog to edit the data, another subroutine (code) to print mailing labels, and so forth. That's a great candidate for an object.

In short, an object is a complete little programming package, code and data, all in one tightly contained place. It's safer and protected, easier to debug, maintain, and reuse. An object can be written to perform most any task you might imagine.

In object terminology, a CLASS is used to define an object. A CLASS is much like an enhanced user-defined type; it's a description of of both the variables and the subroutines which make up the object. When you instruct the compiler to create an object, it uses the definitions found in the CLASS to do so. It allocates memory for the variables, establishes pointers to the subroutines, and makes this new object available to your program.
He further goes on to Say
In our Compiler, objects are optional. Objects are a great programming tool, but your existing procedural code remains fully functional. Standard Subs and Functions will always be supported, so you can blend the techniques at a comfortable pace.
I think this is how OOP should be implemented in PB. :D

I like this statement as it is very right
Thousands of books have been written to describe objects and object oriented programming. In most cases, the buzz words and abstract definitions make it seem as though they're designed to confuse, not enlighten. This seems to put off an average developer!
I hope this is enlightening to someone here like it was to me.

Re: OOP Support (it is time)

Posted: Mon Apr 25, 2011 11:51 am
by DaylightDreamer
Hello guys.
It’s me again.

Like i said before i was going to do a little performance stability test with SimpleOOP .
Look like is pretty stable.
I'm adding a little example.

Code: Select all

Class obj
	
	px.f
	py.f
	mx.f
	my.f
	br.l
	
	Public Release.l = 0
	
	Public Method Init()
		This\px = 512
		This\py = 384
		This\br = 0
		
		This\mx = (Random(400)-200)/100
		This\my = (Random(400)-200)/100
		
		If This\mx = 0 And This\my = 0
			This\Release = 1	
		EndIf
		
	EndMethod
	
	Public Method Update()
		This\px = This\px + This\mx
		This\py = This\py + This\my
		This\br = This\br + 1
		
		If This\br>255
			This\br = 255
		EndIf
		
		If This\px > 1023 Or This\px < 0 Or This\py < 0 Or This\py > 767
			This\Release = 1
		EndIf
		
	EndMethod
	
	Public Method Draw()
		Plot(This\px,This\py,RGB(This\br,This\br,This\br))
	EndMethod
	
	
EndClass

NewList *objects.obj()

InitSprite()
InitKeyboard()

OpenScreen(1024,768,16,"",#PB_Screen_WaitSynchronization ,30)


Repeat
	
	ExamineKeyboard()
	
	
	For r=0 To 10
		AddElement(*objects())
		*objects() = NewObject.obj()
	Next r
	
	cnt = 0
	
	ClearScreen(0)
	
	StartDrawing(ScreenOutput())
	
	ForEach *objects()
		*objects()\Update()
		If *objects()\Release = 1
			*objects() = FreeObject
			DeleteElement(*objects())
		Else
			*objects()\Draw()
			cnt=cnt+1
		EndIf
	Next
	DrawText(10,10,"Objects on screen " + Str(cnt))
	StopDrawing()
	
	FlipBuffers()
Until KeyboardReleased(1)

Re: OOP Support (it is time)

Posted: Mon Apr 25, 2011 2:36 pm
by DaylightDreamer
Zach wrote:That still makes no sense.

I see code on here, that may not be really complex, but has all kinds of complex algorithms or math functions in it, which I know nothing about.
If I want to use it bad enough, or am just really interested.. I'll put in the time to do my best to learn something.

I mean... where do you draw the line in this context? I don't think OOP (or certain elements like simple classes which allow function definitions) as an option is so bad. And don't see how it will split the community in any way at all. Clearly some will know more about OOP than others; but then if they didn't want to spend time helping other people learn they wouldn't be here in the first place?
OOP (class) is basically a set of functions.
So you Draw your line the same way as you would do in case of function.

By the way my example show exactly how to do that.

Re: OOP Support (it is time)

Posted: Sun Jul 03, 2011 8:16 pm
by Zizaco
How do you make an cross-inclusion/dependency of classes using SimpleOOP?

In C++ the solution is to use a forward-declaration in one of the classes (http://stackoverflow.com/questions/1281 ... r-includes), in Java/C# the compiler solve this automatically.
How could you do this in PB+SimpleOOP?