Tweet
hi
i decided to take my cue from dave navarro's comments at http://www.powerbasic.com/support/pb...ead.php?t=2670
and donned my oo hat to try to imagine what oo support in pb might
look like.
first a little background:
traditional oo languages like smalltalk implement objects by defineing
a base class all object derive from. all objects are descended from
this *mother* object. when you want to create a new object you derive
from an existing class which is close to the one you want and override
its methods - you never create an object from scratch. java works
in much the same way.
this has definite overhead and that's a no-no for us powerbasic programmers
since we want fast, tight, lean and mean code.
the alternative is having multiple inheritance where you can inherit
from more than one class. there need be no base object that all
objects are derived from.
while this approach is more efficient it also creates its own problems
and the situation can quickly get messy.
the designer of c++, bjarne stoustrup, recognised this and came up
with the concept of templates (very similar to ada's generics).
a template is basically a parametrised type. when you design a template
you don't specify its type but merely define a holder, or holders
for that/those types. the compiler substitutes the code at compile
time depending on how you "instantiate" the template in your code.
this is a very efficient approach - while i think c++ is a large
and overly complex language a lot of its principles are sound.
here's a very basic attempt at describing a template class in pb
syntax:
the code above would then be used in the following way:
at compile time, the compiler would substitute "t" for the type
passed - note that "t" does not have to be an intrinsic type
but could also be a user defined type or another class.
this kind of design would allow pb, imo, to implement oo very
efficiently. in my view of oo a class is a holder for a set of
operations on a type. the designer of the class can control the
interface, what the user can see (encapsulation). two standard
hooks are defined: the constructor where all the initialization
takes place and the destructor where clean up happens. cleanup
happens when the object goes out of scope.
i know that what i've sketched is very simplistic. hopefully it
illustrates how i picture objects in a future version of pb.
cheers
florent heyworth
[this message has been edited by florent heyworth (edited september 15, 2000).]
i decided to take my cue from dave navarro's comments at http://www.powerbasic.com/support/pb...ead.php?t=2670
and donned my oo hat to try to imagine what oo support in pb might
look like.
first a little background:
traditional oo languages like smalltalk implement objects by defineing
a base class all object derive from. all objects are descended from
this *mother* object. when you want to create a new object you derive
from an existing class which is close to the one you want and override
its methods - you never create an object from scratch. java works
in much the same way.
this has definite overhead and that's a no-no for us powerbasic programmers
since we want fast, tight, lean and mean code.
the alternative is having multiple inheritance where you can inherit
from more than one class. there need be no base object that all
objects are derived from.
while this approach is more efficient it also creates its own problems
and the situation can quickly get messy.
the designer of c++, bjarne stoustrup, recognised this and came up
with the concept of templates (very similar to ada's generics).
a template is basically a parametrised type. when you design a template
you don't specify its type but merely define a holder, or holders
for that/those types. the compiler substitutes the code at compile
time depending on how you "instantiate" the template in your code.
this is a very efficient approach - while i think c++ is a large
and overly complex language a lot of its principles are sound.
here's a very basic attempt at describing a template class in pb
syntax:
Code:
'tarray.inc
template tarray( t )
class array
private
const lsize as long = sizeof( t )
lnumberofelements as long
end private
public
constructor array( byval lelements as long )
lnumberofelements = lelements
array = new t( lnumberofelements )
print "constructor called"
end constructor
destructor array( )
delete array
print "destructor called"
end destructor
function spaceoccupied() as long
function = lsize * lnumberofelements
end function
end public
end class
end template
Code:
#include "tarray.inc"
function pbmain() as long
strarray as tarray( string )
lngarray as tarray( long )
strarray( 20 ) 'create an array of string with 20 elements
print strarray.spaceoccupied()
lngarray( 40 ) 'create an array of long with 40 elements
print lngarray.spaceoccupied()
end function
passed - note that "t" does not have to be an intrinsic type
but could also be a user defined type or another class.
this kind of design would allow pb, imo, to implement oo very
efficiently. in my view of oo a class is a holder for a set of
operations on a type. the designer of the class can control the
interface, what the user can see (encapsulation). two standard
hooks are defined: the constructor where all the initialization
takes place and the destructor where clean up happens. cleanup
happens when the object goes out of scope.
i know that what i've sketched is very simplistic. hopefully it
illustrates how i picture objects in a future version of pb.
cheers
florent heyworth
[this message has been edited by florent heyworth (edited september 15, 2000).]
. I commend you for it.
.
Comment