Hi,
my (german) Help says at the end of the "Interfaces"-Description, that an example for creating own objects is located in the advanced examples in 'PureBasic/Sources'... But I cannot find these examples...
I have seen, that it is possible to create your own objects in PB using Interfaces ( viewtopic.php?t=9553&highlight=components ), but an "official" example would be nice.
Creating Objects
Creating Objects
Last edited by Andras on Mon Feb 21, 2005 6:20 pm, edited 1 time in total.
Undank ist der Welten Lohn
-
Psychophanta
- Always Here
- Posts: 5153
- Joined: Wed Jun 11, 2003 9:33 pm
- Location: Anare
- Contact:
Just jesterday i was looking for samething.
I second your request for an PB "official" example for OOP using Interfaces.
For your help, you can take a look at www.purearea.net in the code-archive section.
I second your request for an PB "official" example for OOP using Interfaces.
For your help, you can take a look at www.purearea.net in the code-archive section.
-
Psychophanta
- Always Here
- Posts: 5153
- Joined: Wed Jun 11, 2003 9:33 pm
- Location: Anare
- Contact:
Re: Creating Objects
BTW
Andras wrote:optical mouse, 17" monitor, keyboard
-
Psychophanta
- Always Here
- Posts: 5153
- Joined: Wed Jun 11, 2003 9:33 pm
- Location: Anare
- Contact:
That's a nice idea.Andras wrote:Hmmm, few people seem to be interested in creating objects/components in PB... But I'm going to write a tool where you will be able to define a 'class' and that will write the resulting PB-Sourcefile...
At viewtopic.php?t=11339 i just tried to understand, but i think it is too much ugly just only to have code in a specific way of sort, the OOP way of sort is not the best way for the apps i make.
However your idea is good.
Andras,
I've been playing with this myself for a while.
The big problem is memory management. As soon as you start creating objects you start to allocate lots of memory and pass it around.
This is why Java, Eiffel and Smalltalk all have garbage collection.
C++ does not have garbage collection, but it does allow the allocation of objects on the stack that are guaranteed to be reclaimed.
Once you have an object has to live beyond the scope of its calling frame you either have to handle all memory management yourself or take complex approaches that depend on strict discipline. For example: http://www.relisoft.com/resource/resmain.html
None of this really lives in the spirit of purebasic. Garbage collection adds runtime overhead and manaul memory management coding complexity.
I've been playing with different ideas, but I'm not going to burden the general population with anything until I have something worthwhile.
At the moment I'm looking at IOC (inversion of control).
With this approach using objects would be rather like using Windows. ie, you request an object from an object engine and provide it with callback functions for your implementation. The allocation and deallocation of memory would all be taken care of by the engine.
Anybody else who is interested in working on this problem with me, I'd appreciate having somebody to bounce ideas off.
I've been playing with this myself for a while.
The big problem is memory management. As soon as you start creating objects you start to allocate lots of memory and pass it around.
This is why Java, Eiffel and Smalltalk all have garbage collection.
C++ does not have garbage collection, but it does allow the allocation of objects on the stack that are guaranteed to be reclaimed.
Once you have an object has to live beyond the scope of its calling frame you either have to handle all memory management yourself or take complex approaches that depend on strict discipline. For example: http://www.relisoft.com/resource/resmain.html
None of this really lives in the spirit of purebasic. Garbage collection adds runtime overhead and manaul memory management coding complexity.
I've been playing with different ideas, but I'm not going to burden the general population with anything until I have something worthwhile.
At the moment I'm looking at IOC (inversion of control).
With this approach using objects would be rather like using Windows. ie, you request an object from an object engine and provide it with callback functions for your implementation. The allocation and deallocation of memory would all be taken care of by the engine.
Anybody else who is interested in working on this problem with me, I'd appreciate having somebody to bounce ideas off.
That would be an option.
It could be optional. During the development the thread could be used to clean up any sessions left open, logging a report every time it does so.
The programmer can use this to make sure that they don't have any memory leaks before going live.
Once they are confident the code is memory tight, they can turn the thread off.
It could be optional. During the development the thread could be used to clean up any sessions left open, logging a report every time it does so.
The programmer can use this to make sure that they don't have any memory leaks before going live.
Once they are confident the code is memory tight, they can turn the thread off.
I would prefer something, that automatically destroys objects... For example the object-engine could own a 'destruction-method' that destroys all objects, that aren't selected to 'survive'. I think it's easier to tell, what should survive, than what should be destroyed.
If we would make the 'mistake' to create an object twice, the object-engine will notice this, because it knows the PointerAddress.
Sorry, if my english is not so good..
Code: Select all
procedure GetASheep.l()
ObjEngine\ProcStart() ; Marking Start- and EndPoints enables us to know, inside of which procedure-depths the objects are created...
Milky.anObj=ObjEngine\GetCow(@Milky)
Dolly.anObj=ObjEngine\GetSheep(@Dolly)
Dolly\Survive() ;Dolly will survive the procedure, Milky won't...
ObjEngine\ProcEnd()
ProcedureReturn(@Dolly)
endprocedureSorry, if my english is not so good..
Undank ist der Welten Lohn
Andras,
This is very different to the approach that I want to take.
The first thing I want to get rid of is the reliance on memory pointers are object identifiers. I would want pointers to be used only locally within a procedure and never passed around as references.
I also want to avoid having to add runtime overhead, such as a separate thread.
Instead of adding complexity at coding time, such as having to deal with strong and weak references, or at runtime, with separate threads having to run, I would like to make the engine simple and transparant.
The objects would be created in a separate space, with the option of sharing between programs in a dll.
The objects would have full reflection. For example, you would be able to query the object engine to list all objects referencing another object. Programmers could use this facility to add automatic resource management if the felt the need.
The objects would have there own lifespan independant of the code using them, with the option for automatic persistance.
The whole thing would have to be small, so that he option of having it statically bound to an executable would be acceptable.
I'd also want to have to methods of using it. Firstly, through interfaces. Secondly, using the Purebasic style of Object usage, such as that used by the Windows library.
I don't want to implement Objects just at they are in every other language. That has alreaedy been done. There is no way I could do something better that SmartEiffel or Ocaml.
I want something that, like Purebasic, does things differently.
This is very different to the approach that I want to take.
The first thing I want to get rid of is the reliance on memory pointers are object identifiers. I would want pointers to be used only locally within a procedure and never passed around as references.
I also want to avoid having to add runtime overhead, such as a separate thread.
Instead of adding complexity at coding time, such as having to deal with strong and weak references, or at runtime, with separate threads having to run, I would like to make the engine simple and transparant.
The objects would be created in a separate space, with the option of sharing between programs in a dll.
The objects would have full reflection. For example, you would be able to query the object engine to list all objects referencing another object. Programmers could use this facility to add automatic resource management if the felt the need.
The objects would have there own lifespan independant of the code using them, with the option for automatic persistance.
The whole thing would have to be small, so that he option of having it statically bound to an executable would be acceptable.
I'd also want to have to methods of using it. Firstly, through interfaces. Secondly, using the Purebasic style of Object usage, such as that used by the Windows library.
I don't want to implement Objects just at they are in every other language. That has alreaedy been done. There is no way I could do something better that SmartEiffel or Ocaml.
I want something that, like Purebasic, does things differently.