Object Class library - CLASSLIB
Post by admin on Apr 21st, 2011, 4:51pm
From time to time I have been asked to provide better support for Object Orientated (OO) programming in BBC BASIC. There have also been a few discussions about this elsewhere, for example:
http://www.riscosopen.org/forum/forums/2/topics/71
http://xania.org/200711/irbasic
These have tended to assume changes to the language itself, and since I am no longer actively developing BB4W such an approach is not attractive. I therefore decided to see what could be achieved using the existing language in conjunction with a 'clever' library. I am pleased to announce the initial release of the Object Classes library CLASSLIB:
http://groups.yahoo.com/group/bb4w/files/Libraries/CLASSLIB.BBC
A key concept in OO languages is the Class. A Class is rather like a structure, except that as well as encapsulating several data items ('members') it also encapsulates the functions used to operate on those items ('methods'). Hence the data and the functions associated with those data are tightly bound together:
http://en.wikipedia.org/wiki/Class_%28computer_programming%29
The Class acts as a prototype from which 'instances' of the class ('objects') are created. Each object has an independent copy of the members.
CLASSLIB supports the main features of the Class/Object paradigm. The file includes details of how it is used, but here is a simple example. We will create a Class representing a circle and the operations one might want to perform on a circle such as calculating its area and its circumference. The first step is to create a regular BB4W structure:
Code: DIM Circle{radius, set_radius, get_area, get_circumference}
Here 'radius' is the data associated with the Class and 'set_radius', 'get_area' and 'get_circumference' are methods which operate on that data. The user may wish to choose a naming convention to make it clear which are the 'members' and which are the 'methods', but CLASSLIB doesn't care.
We now define the various methods, which is done using a variant of the regular DEF statement:
Code: DEF Circle.set_radius (r) Circle.radius = r : ENDPROC
DEF Circle.get_area = PI * Circle.radius^2
DEF Circle.get_circumference = 2 * PI * Circle.radius
Having created the structure and defined the methods we now register it as a class:
Code:
We could also have specified a 'constructor', but for simplicity this example doesn't use one. We can create one or more instances of the class as follows:
Code: PROC_new(mycircle{}, Circle{})
This creates an object 'mycircle{}' on which we can perform operations:
Code: PROC(mycircle.set_radius)(10.0)
PRINT "Area is "; FN(mycircle.get_area)
PRINT "Circumference is "; FN(mycircle.get_circumference)
Note that something interesting is going on here. When the methods are called the member 'Circle.radius' is automatically substituted with the object data 'mycircle.radius'. This is what makes it possible to have multiple concurrent objects all sharing the same methods.
Finally when we've finished with the object we release the memory it occupied:
Code:
Enjoy!
Richard.
Re: Object Class library - CLASSLIB
Post by softweir on Apr 22nd, 2011, 01:39am
Very interesting and ingenious!
Richard Weir.
Re: Object Class library - CLASSLIB
Post by admin on Apr 22nd, 2011, 9:17pm
Another feature provided by most Object Orientated languages is that of 'inheritance'. This allows a subclass to inherit the members and methods from a parent class; this Java example explains it quite well:
http://download.oracle.com/javase/tutorial/java/concepts/inheritance.html
I have updated the CLASSLIB library (v0.5) to support inheritance:
http://tech.groups.yahoo.com/group/bb4w/files/Libraries/CLASSLIB.BBC
Here is a simple example of how inheritance can be used. Suppose we have already created a class to describe an ellipse, with a method to return its area:
Code: DIM Ellipse{a, b, set_size, get_area}
DEF Ellipse.set_size (a,b) Ellipse.a = a : Ellipse.b = b : ENDPROC
DEF Ellipse.get_area = PI * Ellipse.a * Ellipse.b
PROC_class(Ellipse{})
Now suppose we want to create a class for a circle. We could start from scratch, but a circle is a special case of an ellipse so instead we can create a Circle class which inherits from the Ellipse class:
Code: DIM Circle{get_circumference}
PROC_inherit(Circle{}, Ellipse{})
PROC_class(Circle{})
The class inherits the get_area method from its parent, but the Circle class has an extra get_circumference method. For convenience we can override the inherited set_size method with a new version which takes only one parameter (the radius):
Code: DEF Circle.get_circumference = 2 * PI * Circle.a
DEF Circle.set_size (r) Circle.a = r : Circle.b = r : ENDPROC
Now we can use the Circle class:
Code: PROC_new(mycircle{}, Circle{})
PROC(mycircle.set_size)(10.0)
PRINT "Area is "; FN(mycircle.get_area)
PRINT "Circumference is "; FN(mycircle.get_circumference)
PROC_discard(mycircle{})
I hope I have whetted your appetite for Object Orientated programming in BBC BASIC, and look forward to seeing some practical applications.
Richard.
Re: Object Class library - CLASSLIB
Post by admin on May 1st, 2011, 4:10pm
Has anybody tried using CLASSLIB yet?
Those with some previous experience of Object Oriented Programming may have been a little surprised at the syntax I adopted for what in other OO languages is called 'This' (e.g. Java), 'Self' (e.g. Python) or 'Me' (e.g. Visual Basic):
http://en.wikipedia.org/wiki/This_%28computer_programming%29
With CLASSLIB you use the name of the class itself rather than 'This', 'Me' etc. For example to calculate a factorial using a recursive method you could do:
Code: INSTALL @lib$+"CLASSLIB"
DIM Factorial{calculate}
DEF Factorial.calculate (n) IF n<=1 THEN =n ELSE = n*FN(Factorial.calculate)(n-1)
PROC_class(Factorial{})
PROC_new(myfact{}, Factorial{})
PRINT "Factorial 6 = ";FN(myfact.calculate)(6)
PRINT "Factorial 7 = ";FN(myfact.calculate)(7)
PROC_discard(myfact{})
I initially tried to use a special name such as '@This' but it wasn't compatible with being compiled (with crunching enabled).
Below I've listed a simple Object Oriented 'Towers of Hanoi' program (you will need the latest CLASSLIB, version 0.6, for it to run successfully); it uses recursive method calls.
Richard.
Code: INSTALL @lib$+"CLASSLIB"
OFF
DIM Hanoi{peg(3), @, solve, take, put, show}
PROC_class(Hanoi{})
PROC_new(puzzle{}, Hanoi{})
WAIT 100
PROC(puzzle.solve)(12,1,2,3)
PROC_discard(puzzle{})
REPEAT UNTIL INKEY(1)=0
DEF Hanoi.@ LOCAL n : FOR n=12 TO 1 STEP -1 : PROC(Hanoi.put)(n,1) : NEXT : ENDPROC
DEF Hanoi.take (n,p) Hanoi.peg(p)-=1 : COLOUR 143 : PROC(Hanoi.show)(n,p) : ENDPROC
DEF Hanoi.put (n,p) COLOUR 128+n : PROC(Hanoi.show)(n,p) : Hanoi.peg(p)+=1 : ENDPROC
DEF Hanoi.show (n,p) PRINT TAB(26*p-n-10, 20-Hanoi.peg(p)) SPC(2*n); : ENDPROC
DEF Hanoi.solve (a,b,c,d) IF a=0 THEN ENDPROC
PROC(Hanoi.solve)(a-1,b,d,c)
PROC(Hanoi.take)(a,b)
PROC(Hanoi.put)(a,c)
PROC(Hanoi.solve)(a-1,d,c,b)
ENDPROC
Re: Object Class library - CLASSLIB
Post by Michael Hutton on May 9th, 2011, 02:31am
Quote:Has anybody tried using CLASSLIB yet?
|
|
here goes...
Functions to duplicate objects would be good... Could using structure arrays be possible <thinking aloud before going to bed> to create multiple objects of the same type but easily referenced.. but I feel that is not in the 'spirit' of OOP...rather than having to type in the name for each... hmm.. yawn.. tired... making no sense... ZZzzzzzzzzzzzzzz
I am sure there is a better way of writing this...
Code: REM A random Walk through Object Biomorph land...
REM Michael Hutton May 2011
REM based on Biomorphs by Mike Cook (c) Micro user
REM Works in demo version of BB4W
MODE 8
INSTALL @lib$+"CLASSLIB"
OFF
g_Index% = -1
DIM Biomorph{index, gene(5), generation, x, y, @, _draw, _grow, _mutate, _givegenes}
PROC_class(Biomorph{})
PROC_new(p{}, Biomorph{})
PROC_new(a{}, Biomorph{})
PROC_new(b{}, Biomorph{})
PROC_new(c{}, Biomorph{})
PROC_new(d{}, Biomorph{})
PROC_new(e{}, Biomorph{})
PROC_new(f{}, Biomorph{})
PROC_new(g{}, Biomorph{})
PROC_new(h{}, Biomorph{})
PROC_new(i{}, Biomorph{})
PROC_new(j{}, Biomorph{})
PROC_new(k{}, Biomorph{})
PROC_new(l{}, Biomorph{})
*REFRESH OFF
ON ERROR OSCLI"REFRESH ON" : PRINT REPORT$ : ON : PROC0
Stop% = FALSE
REPEAT
K$ = INKEY$(1)
CASE K$ OF
WHEN "s","S" : Stop% = TRUE
WHEN "r","R" : REM erm.. to do : reset objects
WHEN " " : REPEAT: UNTIL INKEY(1) = 32
ENDCASE
REM Mutate the children (!)
PROC(a._mutate):PROC(b._mutate):PROC(c._mutate):PROC(d._mutate):PROC(e._mutate):PROC(f._mutate)
PROC(g._mutate):PROC(h._mutate):PROC(i._mutate):PROC(j._mutate):PROC(k._mutate):PROC(l._mutate)
CLS
REM Draw Biomorphs
PROC(p._draw)
PROC(a._draw):PROC(b._draw):PROC(c._draw):PROC(d._draw):PROC(e._draw):PROC(f._draw)
PROC(g._draw):PROC(h._draw):PROC(i._draw):PROC(j._draw):PROC(k._draw):PROC(l._draw)
*REFRESH
REM Choose a random Parent from the children
CASE RND(12) OF
WHEN 1: PROC(a._givegenes)(p{})
WHEN 2: PROC(b._givegenes)(p{})
WHEN 3: PROC(c._givegenes)(p{})
WHEN 4: PROC(d._givegenes)(p{})
WHEN 5: PROC(e._givegenes)(p{})
WHEN 6: PROC(f._givegenes)(p{})
WHEN 7: PROC(g._givegenes)(p{})
WHEN 8: PROC(h._givegenes)(p{})
WHEN 9: PROC(i._givegenes)(p{})
WHEN 10: PROC(j._givegenes)(p{})
WHEN 11: PROC(k._givegenes)(p{})
WHEN 12: PROC(l._givegenes)(p{})
ENDCASE
PROC(p._givegenes)(a{})
PROC(p._givegenes)(b{})
PROC(p._givegenes)(c{})
PROC(p._givegenes)(d{})
PROC(p._givegenes)(e{})
PROC(p._givegenes)(f{})
PROC(p._givegenes)(g{})
PROC(p._givegenes)(h{})
PROC(p._givegenes)(i{})
PROC(p._givegenes)(j{})
PROC(p._givegenes)(k{})
PROC(p._givegenes)(l{})
UNTIL Stop%
*REFRESH ON
ON
DEF PROC0
PROC_discard(p{})
PROC_discard(a{})
PROC_discard(b{})
PROC_discard(c{})
PROC_discard(d{})
PROC_discard(e{})
PROC_discard(f{})
PROC_discard(g{})
PROC_discard(h{})
PROC_discard(i{})
PROC_discard(j{})
PROC_discard(k{})
PROC_discard(l{})
END
DEF Biomorph.@
g_Index% += 1
Biomorph.index = g_Index%
Biomorph.gene(0) = 5
Biomorph.gene(1) = 20
Biomorph.gene(2) = .785
Biomorph.gene(3) = 1
Biomorph.gene(4) = 0
Biomorph.gene(5) = 0
Biomorph.generation = 0
IF g_Index% THEN
Biomorph.x = 640 + (400*SIN(g_Index%*PI/6))
Biomorph.y = 512 + (400*COS(g_Index%*PI/6))
ELSE
Biomorph.x = 640
Biomorph.y = 512
ENDIF
ENDPROC
DEF Biomorph._draw
D = Biomorph.gene(0)
L = Biomorph.gene(1)
dA = Biomorph.gene(2)
AR = Biomorph.gene(3)
DT = Biomorph.gene(4)
DS = Biomorph.gene(5)
X = Biomorph.x
Y = Biomorph.y
MOVE X,Y
DRAW X,Y-L
PROC(Biomorph._grow)(PI/2,L,X,Y,D)
ENDPROC
DEF Biomorph._grow (TH,L,X,Y,D)
IF D MOVE X,Y ELSE ENDPROC
dX=L*COS(TH+dA)*(1/AR)
dY=L*SIN(TH+dA)*AR
PLOT 1,dX,dY
PROC(Biomorph._grow)(TH+dA+DT,L-DS,X+dX,Y+dY,D-1)
MOVE X,Y
dX=L*COS(TH-dA)*(1/AR)
dY=L*SIN(TH-dA)*AR
PLOT 1,dX,dY:MOVE X,Y
PROC(Biomorph._grow)(TH-dA-DT,L-DS,X+dX,Y+dY,D-1)
ENDPROC
DEF Biomorph._mutate
LOCAL I%, S%, f
I% = (Biomorph.index-1)DIV2
IF (Biomorph.index MOD 2) THEN S% = 1 ELSE S% = -1
f = RND(1)
CASE Biomorph.index OF
WHEN 1:
Biomorph.gene(0) -= 1
IF Biomorph.gene(0) =0 THEN Biomorph.gene(0) = 1
WHEN 2:
Biomorph.gene(0) += 1
IF Biomorph.gene(0) > 8 THEN Biomorph.gene(0) = 8
WHEN 3,4:
Biomorph.gene(1) += RND(1)-0.5
IF Biomorph.gene(1)<1 THEN Biomorph.gene(1) = 1
IF Biomorph.gene(1)>40 THEN Biomorph.gene(1) = 40
WHEN 5,6:
Biomorph.gene(2) += (RND(1)-0.5)*0.5
IF Biomorph.gene(2)>2*PI THEN Biomorph.gene(2) -= 2*PI
IF Biomorph.gene(2)<0 THEN Biomorph.gene(2) += 2*PI
WHEN 7,8
Biomorph.gene(3) += (RND(1)-0.5)*0.5
IF Biomorph.gene(3)<0.1 THEN Biomorph.gene(3) = 0.1
IF Biomorph.gene(3)>10 THEN Biomorph.gene(3) = 10
WHEN 9,10:
Biomorph.gene(4) += (RND(1)-0.5)*0.5
IF Biomorph.gene(4)>2*PI THEN Bimorph.gene(2) -= 2*PI
IF Biomorph.gene(4)<0 THEN Biomorph.gene(2) += 2*PI
WHEN 11,12:
Biomorph.gene(5) += (RND(1)-0.5)*0.5
IF Biomorph.gene(5)<-18 THEN Biomorph.gene(5) = -18
IF Biomorph.gene(5)>18 THEN Biomorph.gene(5) = 18
ENDCASE
ENDPROC
DEF Biomorph._givegenes (t{})
LOCAL I%
FOR I%=0TO5
t.gene(I%) = Biomorph.gene(I%)
NEXT
ENDPROC
Re: Object Class library - CLASSLIB
Post by admin on May 9th, 2011, 2:58pm
on May 9th, 2011, 02:31am, Michael Hutton wrote:| Functions to duplicate objects would be good... |
|
I'm not too sure why you would want to, but I think you can duplicate an object as follows:
Code: DIM Copy{} = Object{}
Copy{} = Object{}
PROC_class(Copy{})
Richard.
Re: Object Class library - CLASSLIB
Post by admin on May 9th, 2011, 5:08pm
on May 9th, 2011, 02:31am, Michael Hutton wrote:| Could using structure arrays be possible |
|
Again, I don't think you need any modifications to the library to achieve that. The only issue is how to create the structure array in the first place; one rather inelegant way is this:
Code: REM A random Walk through Object Biomorph land...
REM Michael Hutton May 2011
REM based on Biomorphs by Mike Cook (c) Micro user
REM Works in demo version of BB4W
MODE 8
INSTALL @lib$+"CLASSLIB"
OFF
g_Index% = -1
DIM Biomorph{index, gene(5), generation, x, y, @, _draw, _grow, _mutate, _givegenes}
PROC_class(Biomorph{})
DIM morph{(12) dummy&}
FOR I% = 0 TO 12
PROC_new(morph{(I%)}, Biomorph{})
NEXT
*REFRESH OFF
ON ERROR OSCLI"REFRESH ON" : PRINT REPORT$ : ON : PROC0
Stop% = FALSE
REPEAT
K$ = INKEY$(1)
CASE K$ OF
WHEN "s","S" : Stop% = TRUE
WHEN "r","R" : REM erm.. to do : reset objects
WHEN " " : REPEAT: UNTIL INKEY(1) = 32
ENDCASE
REM Mutate the children (!)
FOR I% = 1 TO 12
PROC(morph{(I%)}._mutate)
NEXT
CLS
REM Draw Biomorphs
FOR I% = 0 TO 12
PROC(morph{(I%)}._draw)
NEXT
*REFRESH
REM Choose a random Parent from the children
PROC(morph{(RND(12))}._givegenes)(morph{(0)})
FOR I% = 1 TO 12
PROC(morph{(0)}._givegenes)(morph{(I%)})
NEXT
UNTIL Stop%
*REFRESH ON
ON
DEF PROC0
FOR I% = 0 TO 12
PROC_discard(morph{(I%)})
NEXT
END
DEF Biomorph.@
g_Index% += 1
Biomorph.index = g_Index%
Biomorph.gene(0) = 5
Biomorph.gene(1) = 20
Biomorph.gene(2) = .785
Biomorph.gene(3) = 1
Biomorph.gene(4) = 0
Biomorph.gene(5) = 0
Biomorph.generation = 0
IF g_Index% THEN
Biomorph.x = 640 + (400*SIN(g_Index%*PI/6))
Biomorph.y = 512 + (400*COS(g_Index%*PI/6))
ELSE
Biomorph.x = 640
Biomorph.y = 512
ENDIF
ENDPROC
DEF Biomorph._draw
D = Biomorph.gene(0)
L = Biomorph.gene(1)
dA = Biomorph.gene(2)
AR = Biomorph.gene(3)
DT = Biomorph.gene(4)
DS = Biomorph.gene(5)
X = Biomorph.x
Y = Biomorph.y
MOVE X,Y
DRAW X,Y-L
PROC(Biomorph._grow)(PI/2,L,X,Y,D)
ENDPROC
DEF Biomorph._grow (TH,L,X,Y,D)
IF D MOVE X,Y ELSE ENDPROC
dX=L*COS(TH+dA)*(1/AR)
dY=L*SIN(TH+dA)*AR
PLOT 1,dX,dY
PROC(Biomorph._grow)(TH+dA+DT,L-DS,X+dX,Y+dY,D-1)
MOVE X,Y
dX=L*COS(TH-dA)*(1/AR)
dY=L*SIN(TH-dA)*AR
PLOT 1,dX,dY:MOVE X,Y
PROC(Biomorph._grow)(TH-dA-DT,L-DS,X+dX,Y+dY,D-1)
ENDPROC
DEF Biomorph._mutate
LOCAL I%, S%, f
I% = (Biomorph.index-1)DIV2
IF (Biomorph.index MOD 2) THEN S% = 1 ELSE S% = -1
f = RND(1)
CASE Biomorph.index OF
WHEN 1:
Biomorph.gene(0) -= 1
IF Biomorph.gene(0) =0 THEN Biomorph.gene(0) = 1
WHEN 2:
Biomorph.gene(0) += 1
IF Biomorph.gene(0) > 8 THEN Biomorph.gene(0) = 8
WHEN 3,4:
Biomorph.gene(1) += RND(1)-0.5
IF Biomorph.gene(1)<1 THEN Biomorph.gene(1) = 1
IF Biomorph.gene(1)>40 THEN Biomorph.gene(1) = 40
WHEN 5,6:
Biomorph.gene(2) += (RND(1)-0.5)*0.5
IF Biomorph.gene(2)>2*PI THEN Biomorph.gene(2) -= 2*PI
IF Biomorph.gene(2)<0 THEN Biomorph.gene(2) += 2*PI
WHEN 7,8
Biomorph.gene(3) += (RND(1)-0.5)*0.5
IF Biomorph.gene(3)<0.1 THEN Biomorph.gene(3) = 0.1
IF Biomorph.gene(3)>10 THEN Biomorph.gene(3) = 10
WHEN 9,10:
Biomorph.gene(4) += (RND(1)-0.5)*0.5
IF Biomorph.gene(4)>2*PI THEN Bimorph.gene(2) -= 2*PI
IF Biomorph.gene(4)<0 THEN Biomorph.gene(2) += 2*PI
WHEN 11,12:
Biomorph.gene(5) += (RND(1)-0.5)*0.5
IF Biomorph.gene(5)<-18 THEN Biomorph.gene(5) = -18
IF Biomorph.gene(5)>18 THEN Biomorph.gene(5) = 18
ENDCASE
ENDPROC
DEF Biomorph._givegenes (t{})
LOCAL I%
FOR I%=0TO5
t.gene(I%) = Biomorph.gene(I%)
NEXT
ENDPROC
Richard.
Re: Object Class library - CLASSLIB
Post by Michael Hutton on May 9th, 2011, 5:48pm
Quote:
...but not that inelegant compared with what I have just been doing! I had thought of a dummy variable but using PROC_inherit rather than your method. I *think* (really not sure atm) I realised it wasn't the way to go. I then resorted to saving the pointers of the structure in their own list as in this code :
Code:
REM Particles with CLASSLIB
REM Won't be fast...proof of concept
REM Just to test the idea of 'anonymous' objects
REM ie all the objects are called the same
REM we track them by saving their pointers
MODE 8
INSTALL @lib$+"CLASSLIB"
MaxParticles% = 50
NParticles% = 5
REM Array of structures to hold Object pointers
DIM pParticle{(MaxParticles%) fba%, dba%}
DIM Particle{x,y,vx,vy,creationtime,life,@,_draw,_move,_check,_kill,_spawn}
PROC_class(Particle{})
REM Create particle objects and save their pointers
FOR I%=1 TO NParticles%
PROC_new(particle{}, Particle{})
pParticle{(I%)}.fba% = !^particle{}
pParticle{(I%)}.dba% = !(^particle{}+4)
NEXT
REM Set the particle{} pointers to null for a giggle
!^particle{} = 0 : !(^particle{}+4) = 0
REPEAT
FOR I%=1 TO MaxParticles%
IF pParticle{(I%)}.fba% THEN
!^particle{} = pParticle{(I%)}.fba%
!(^particle{}+4) = pParticle{(I%)}.dba%
PROC(particle._draw)
PROC(particle._move)
PROC(particle._check)
ENDIF
NEXT
UNTIL INKEY(1) = 32
REM Destroy the particles
FOR I%=1 TO MaxParticles%
IF pParticle{(I%)}.fba% THEN
!^particle{} = pParticle{(I%)}.fba%
!(^particle{}+4) = pParticle{(I%)}.dba%
PROC_discard(particle{})
ENDIF
NEXT
END
DEF Particle.@
Particle.x = RND(600)+200 : Particle.y = RND(600)+200
Particle.vx = (RND(1)-0.5) * 16
Particle.vy = (RND(1)-0.5) * 16
Particle.creationtime = TIME
Particle.life = RND(200)+500
ENDPROC
DEF Particle._draw PLOT 69, Particle.x, Particle.y : ENDPROC
DEF Particle._move
Particle.x += Particle.vx : Particle.y += Particle.vy
IF Particle.x < 200 THEN Particle.x = 200 : Particle.vx *=-1
IF Particle.x > 800 THEN Particle.x = 800 : Particle.vx *=-1
IF Particle.y < 200 THEN Particle.y = 200 : Particle.vy *=-1
IF Particle.y > 800 THEN Particle.y = 800 : Particle.vy *=-1
ENDPROC
DEF Particle._check
IF (TIME - Particle.creationtime) > Particle.life THEN
REM IF RND(5) = 1 THEN PROC(Particle._spawn)(RND(5))
PROC(Particle._kill)
ENDIF
ENDPROC
DEF Particle._kill
PROC_discard(Particle{})
pParticle{(I%)}.fba% = 0
pParticle{(I%)}.dba% = 0
ENDPROC
DEF Particle._spawn (n%)
LOCAL I%, J%
FOR I%=1 TO n%
J% = 1
WHILE pParticle{(J%)}.fba% AND J%<>0 : J% = (J%+1) MOD MaxParticles% : ENDWHILE
PRINT J%
IF J%=0 THEN EXIT FOR
REM Doesn't like this..
PROC_new(particle{}, Particle{})
pParticle{(J%)}.fba% = !^particle{}
pParticle{(J%)}.dba% = !(^particle{}+4)
NEXT
ENDPROC
which, although runs, doesn't like me trying to 'spawn' more objects within Particle._spawn - which I don't see why just at the moment. I think I could see this maybe working more elegantly with the {()} method.
Michael
Re: Object Class library - CLASSLIB
Post by admin on May 11th, 2011, 08:55am
on May 9th, 2011, 5:48pm, Michael Hutton wrote:| ...but not that inelegant compared with what I have just been doing! |
|
Indeed! In fact the more I think about it the more I'm convinced there is no better way of creating the structure array than the one I listed (using a 'dummy' member).
The way DIM is coded means (reasonably enough I think) that you can't create a structure array in which the structures are 'empty'. So the best you can do is to make the structures as small as possible (one byte) so that when they are re-used as objects only the minimum amount of memory is wasted.
Richard.
Re: Object Class library - CLASSLIB
Post by Andy Parkes on Feb 10th, 2014, 09:48am
Hi Folks,
I'm a little confused about CLASSLIBs implementation of containment. CLASSLIB seems to get confused when multiple constructors are involved. In the example below, an instance of Class1 is contained in Class2. Both classes have a user-defined constructor. When creating an new instance of Class2, I would have expected the constructor for Class2 to be called, regardless of whether the contained class has a constructor.
Code:
INSTALL @lib$ + "CLASSLIB"
PRINT "Contained class has user-defined constructor"'
DIM Class1{member1%, @Class1,@@Class1}
PROC_class(Class1{})
DIM Class2{member2%,Contained{}=Class1{}, @Class2,@@Class2}
PROC_class(Class2{})
PROC_new(Obj{},Class2{})
PROC_discard(Obj{})
PRINT '"Contained class noes not have user-defined constructor"'
DIM Class3{member1%}
PROC_class(Class3{})
DIM Class4{member2%,Contained{}=Class3{}, @Class4,@@Class4}
PROC_class(Class4{})
PROC_new(Obj{},Class4{})
PROC_discard(Obj{})
END
DEF Class1.@Class1
PRINT "In Class1 Constructor"
ENDPROC
DEF Class1.@@Class1
PRINT "In Class2 Destructor"
ENDPROC
DEF Class2.@Class2
PRINT "In Class2 Constructor"
ENDPROC
DEF Class2.@@Class2
PRINT "In Class2 Destructor"
ENDPROC
DEF Class4.@Class4
PRINT "In Class4 Constructor"
ENDPROC
DEF Class4.@@Class4
PRINT "In Class4 Destructor"
ENDPROC
Am I correct in thinking that containment is only supported for classes that do not have a user-defined constructor and destructor?
Thanks
Andy
Re: Object Class library - CLASSLIB
Post by admin on Feb 10th, 2014, 9:36pm
on Feb 10th, 2014, 09:48am, Andy Parkes wrote:| When creating an new instance of Class2, I would have expected the constructor for Class2 to be called, regardless of whether the contained class has a constructor. |
|
It would be, had you defined Class2 like this:
Code:
DIM Class2{member2%, @Class2, @@Class2, Contained{}=Class1{}}
Specifically, the constructor is the first method in the class definition which starts with an @, so if both the 'contained' class and the 'container' class have a constructor, which is called depends on the order in which they appear. There is no way to arrange for both constructors to be called, if that is what you would have preferred (you could always arrange for the 'container' class's constructor explicitly to call the 'contained' class's constructor).
Please note that I don't know the first thing about Object Oriented Programming. The above comments are based on my very limited understanding of the code in CLASSLIB. The person who would be in a better position to answer is Jon Ripley, but as far as I'm aware he is no longer a BBC BASIC user.
Richard.
Re: Object Class library - CLASSLIB
Post by Andy Parkes on Feb 12th, 2014, 11:07am
Thanks Richard,
Quote:if both the 'contained' class and the 'container' class have a constructor, which is called depends on the order in which they appear.
|
|
I see that now. I have had a closer look at CLASSLIB and made some modifications and uploaded the resulting alternative version of the library:
http://wiggio.com/yui/folder/stream_file.php?doc_key=UPj0PFAQhZunxxI9QgkanItctTc9D7wqtcAF2cmYrtg=
I have made the following changes:
1...
It is no longer a requirement that the user write a constructor member before contained class members. This is because it ignores all contained class constructors and leaves their execution to the discretion of the class designer.
I was in two minds about this idea to begin with, as it seemed like the previous way of doing things (by choosing one constructor to call based upon the order of the class structure members) was more flexible. After a little more thought, I've concluded that it is probably less flexible, potentially the cause of an insidious bug (which is how I have come across it), and does not seem to have an analogue in OOP languages. The fact that the class designer would have to 'manually' call the contained-class-destructors within the container-class-destructor anyway, also added to my feeling that this new system is clearer by virtue of being consistent. In terms of flexibility, it allows for constructors that take parameters, and also a choice of initialisation routines (what in other languages might be implemented as overloaded constructors) for contained classes.
2...
It allows constructors to take parameters (as mentioned).
3...
It allows new objects to be assigned to LOCAL structure variables.
I've done this by asking the user to pass the address of the structure variable to which they want to assign the new object, I could not see a neater way of doing this.
Quote:There is no way to arrange for both constructors to be called...
|
|
For once I have to disagree with you, I can see some ways of implementing that with some sort of stack, but it would eliminate the other advantages I mentioned above. It would also lead to reduced performance and even greater complexity, in what is already fairly esoteric code.
I've documented the changes at the beginning of the library. Only superficial modifications were needed to implement the ideas I've mentioned so I hope that I have not introduced any bugs.
CLASSLIB (and CLASSLIBA 
) is a really powerful addition to BB4W. I wish I had realised its potential sooner. Just as some problems lend themselves particularly well for example, to recursion (and so we might keep that discipline in our tool kit), so I'm learning, that some problems are solved just beautifully with objects.
Andy
Re: Object Class library - CLASSLIB
Post by admin on Feb 12th, 2014, 1:46pm
on Feb 12th, 2014, 11:07am, Andy Parkes wrote:| I have had a closer look at CLASSLIB and made some modifications |
|
I'm impressed that you were able to make modifications to what I often consider to be a 'read only' library, because its code is so incomprehensible!
Quote:I have made the following changes:
1. It is no longer a requirement that the user write a constructor member before contained class members. |
|
I think I understand the modification you have made, except that I can't figure out what your X% = 1 achieves. As far as I can see the functionality would not be affected if it was omitted.
Quote:| 2. It allows constructors to take parameters (as mentioned). |
|
I notice that you have achieved this in such a way as to make your modified library incompatible with the original. That was obviously deliberate, but it rules out your library replacing the current one.
Quote:| 3. It allows new objects to be assigned to LOCAL structure variables. I've done this by asking the user to pass the address of the structure variable |
|
The inelegant syntax seems a high price to pay for the ability to make a new object LOCAL.
In any case, making the object LOCAL is likely to result in a memory leak (that's precisely why it is prohibited using the conventional syntax). When the PROC or FN in which it is declared returns, the reference to the object will be lost but the memory occupied by the object won't automatically be freed. So every iteration will result in a new block of memory being allocated.
To avoid this problem you would need to PROC_discard the 'local' object prior to returning from the PROC/FN, in which case you might as well make it PRIVATE rather than LOCAL and thereby retain the more elegant syntax.
Quote:| For once I have to disagree with you, I can see some ways of implementing that... |
|
Sorry if it wasn't obvious, but when saying there is "no way" I (naturally) meant using the existing CLASSLIB library. I wasn't considering the possibility of modifying the library.
Richard.
Re: Object Class library - CLASSLIB
Post by Andy Parkes on Feb 12th, 2014, 7:46pm
Quote:I think I understand the modification you have made, except that I can't figure out what your X% = 1 achieves. As far as I can see the functionality would not be affected if it was omitted.
|
|
Yes, your right its overkill, it might spare an IF statement, but it always creates an assignment, so I'll remove it.
Quote:you might as well make it PRIVATE rather than LOCAL and thereby retain the more elegant syntax.
|
|
I take your point, but my motivation was to avoid the need for global and PRIVATE variables, which stems from the way I have picked up the warning given in the PRIVATE help topic:
http://www.bbcbasic.co.uk/bbcwin/manual/bbcwin7.html#private
As a result, I try to avoid using PRIVATE variables as much as possible. I would favour the most robust solution, as it outweighs elegant syntax. But I admit that I don't fully understand the complications surrounding PRIVATE variables, so I wonder now if this is another example of overkill? I very much welcome being assured that it is.
In particular, I have never been entirely clear about the following statement:
“it is important to ensure that no errors occur whilst PRIVATE variables are in use”
I realise that it is still fine to use ON ERROR for exception handling, so what is meant by 'in use'?
Or have I taken this out of context, is the restriction specific to recursive functions with PRIVATE variables?
Quote:Sorry if it wasn't obvious, but when saying there is "no way" I (naturally) meant using the existing CLASSLIB library. I wasn't considering the possibility of modifying the library.
|
|
Re-reading your message, I'm not sure how I misunderstood. Anyway, I should have guessed that you would be able to see the possible solutions if I can.
Andy
Re: Object Class library - CLASSLIB
Post by admin on Feb 12th, 2014, 9:10pm
on Feb 12th, 2014, 7:46pm, Andy Parkes wrote:| But I admit that I don't fully understand the complications surrounding PRIVATE variables, so I wonder now if this is another example of overkill? |
|
Well, equally I don't fully understand what your anxiety is, so it's hard for me to comment. Given that PRIVATE was one of the more challenging features to add to BBC BASIC I would be pretty frustrated if people avoided its use!
Quote:| what is meant by 'in use'? |
|
By 'in use' I mean after one or more PRIVATE statements have been executed but before the ENDPROC or end-of-function. In other words, whilst one or more PRIVATE variables are 'in scope'.
Quote:| is the restriction specific to recursive functions with PRIVATE variables? |
|
The issue to which the warning refers is the possibility of a function containing PRIVATE variables being accidentally called re-entrantly, typically because an error occurred during its execution.
The combination of circumstances in which this might happen is pretty unlikely. Firstly errors must be trapped (otherwise there's no way the function can be called again after the error occurred). Secondly the error must occur within the scope of a PRIVATE variable, either because the code of the function itself fails or as the result of an asynchronous event such as pressing Escape.
And even if this unlikely situation can occur any untoward consequences can be avoided by a judicious use of 'ON ERROR LOCAL'. Many of my programs contain several of these unwieldy statements:
Code: ON ERROR LOCAL RESTORE LOCAL : ERROR ERR, REPORT$
Richard.
Re: Object Class library - CLASSLIB
Post by Andy Parkes on Feb 13th, 2014, 11:25am
Quote:By 'in use' I mean after one or more PRIVATE statements have been executed but before the ENDPROC or end-of-function. In other words, whilst one or more PRIVATE variables are 'in scope'.
|
|
Thank you, I wasn’t sure if it had meant simply after their declaration (in scope or otherwise), and so I could not see the logical reasons why the use of PRIVATE variables in specific situations, might result in code with a potential bug. While I do often use private variables, in my ignorance I have been cautious. In practice, this has mostly meant that I have tended to avoided their use in reusable/library code.
So, I have gladly removed the need to pass a structure variable pointer in CLASSLIBA, and have taken the opportunity to re-introduce PROC_new() for compatibility with CLASSLIB. Incompatibility will occur only if a class definition relies upon a contained-class-constructor being called when a new object is instantiated.
http://wiggio.com/yui/folder/stream_file.php?doc_key=/tcVC37nCLqGWtAobYPK4NgJeZvtKr1Det6E0IZGWNU=
Thanks again
Andy
Re: Object Class library - CLASSLIB
Post by admin on Feb 13th, 2014, 2:45pm
on Feb 13th, 2014, 11:25am, Andy Parkes wrote:| have taken the opportunity to re-introduce PROC_new() for compatibility with CLASSLIB. |
|
At some point I may consider incorporating in the 'official' CLASSLIB some features similar to those you have added. But before doing that I would be interested to hear from other users whether they would find them useful.
In particular do people feel that being able to pass parameters to 'new' is a worthwhile enhancement compared with explicitly calling a constructor? In other words is there a significant advantage in doing:
Code: PROC(FN_new(myObject{}, myClass{}))(parameters)
compared with the existing method:
Code: PROC_new(myObject{}, myClass{})
PROC(myObject.ctor)(parameters)
My own feeling is that it's hard to justify the extra complexity in the library for what amounts to syntactic sugar, but as I'm not an OO programmer I'm not the best person to judge.
Richard.
Re: Object Class library - CLASSLIB
Post by Andy Parkes on Feb 13th, 2014, 7:52pm
Many objects need just one constructor (with parameters), and so in those cases the existing syntax does not enforce the class API. It would be possible for someone to instantiate an object which requires a constructor, without calling that constructor, and it would be possible for different class designers to use different names for their constructor. Encapsulating the constructor is obviously a good idea. However, where more than one constructor is needed, the client will still have to be aware of which constructor to call, in which case there is no disadvantage to using the existing syntax.
So basically, the 'proposed' syntax provides encapsulation in one additional case relative to the existing syntax, i.e. when only one constructor with parameters is required.
I agree that it amounts to syntactic sugar, and I don't know if it was worth adding those bits-and-bobs. So I would also be interested to see what other people think.
It occurred to me that it might be possible to simulate polymorphism for constructors, but I have some very ugly code in mind (involving error trapping), that if it worked, would result in very sweet syntax, but it would be going against the grain of BB4W. I think CLASSLIB strikes such an excellent balance, and is so compact, that its right to carefully consider small changes.
Andy
Re: Object Class library - CLASSLIB
Post by Andy Parkes on Mar 7th, 2014, 11:57am
Hi folks,
I have made another change to CLASSLIBA that is possibly worth mentioning:
http://wiggio.com/yui/folder/stream_file.php?doc_key=ck73Bdku6hyAO+SzuM5KN0kYaKtjKAlqhvXG7mwovhQ=
The change allows arrays to be passed as arguments to methods (as is normal for other functions and procedures). For example, the following code does not work with CLASSLIB:
Code:
INSTALL @lib$ + "CLASSLIB"
DIM Class{method1, method2}
PROC_class(Class{})
PROC_new(Obj{},Class{})
PROC(Obj.method1)
PROC_discard(Obj{})
END
DEF Class.method1
LOCAL a%(), A%
DIM a%(10)
FOR A%=1 TO 10
a%(A%) = A%
NEXT
PROC(Class.method2)(a%())
ENDPROC
DEF Class.method2 (a%())
LOCAL A%
FOR A%=1 TO DIM(a%(),1)
PRINT a%(A%)
NEXT
ENDPROC
I have also added a tiny bit more syntactic-sugar, but you can easily delete anything you find unnecessary.
Thanks
Andy
Re: Object Class library - CLASSLIB
Post by Andy Parkes on Mar 7th, 2014, 12:08pm
Hi folks,
I found a bug immediately after uploading, so have deleted CLASSLIBA for the time being, and will upload it again later after its fixed.
Thanks
Andy
Re: Object Class library - CLASSLIB
Post by admin on Mar 7th, 2014, 1:32pm
on Mar 7th, 2014, 11:57am, Andy Parkes wrote:| The change allows arrays to be passed as arguments to methods (as is normal for other functions and procedures). |
|
In case you thought otherwise, the inability to accept array parameters is a bug, not an intentional 'feature' of CLASSLIB! Clearly it needs to be rectified in the 'official' library, rather than being treated as an 'extension'.
I have therefore corrected CLASSLIB.BBC to accept arrays as formal parameters of methods. Version 0.95 may be downloaded from here.
Richard.
Re: Object Class library - CLASSLIB
Post by Andy Parkes on Mar 7th, 2014, 3:25pm
Here is CLASSLIBA with it's spoonful syntactic-sugar:
http://wiggio.com/yui/folder/stream_file.php?doc_key=phUocicEhoLWSL0X5QClkwa8dRM+l0mRNT8+YQV1wfc=
Before uploading, I solved the issue with the same method, only implementing a FOR loop. Before that my failed attempt used INSTR thinking that I could achieve better performance, but it created some delicate situations. Now having now seen your solution, I have copied it as its more elegant, and it keeps CLASSLIBA fundamentally identical to CLASSLIB.
Many Thanks
Andy
Re: Object Class library - CLASSLIB
Post by Andy Parkes on Mar 7th, 2014, 3:55pm
I did it again 
So, for the sake of completeness (its not as if it contains critical updates), here is CLASSLIBA:
http://wiggio.com/yui/folder/stream_file.php?doc_key=MHvXkkJzqZm9Mis20GYpjikqHzEoRjLcTFe1wSLHhYs=
Many thanks,
Andy
Re: Object Class library - CLASSLIB
Post by rtr on Jun 4th, 2014, 5:46pm
I have updated CLASSLIB to version 0.96. It may be downloaded from here:
http://wiggio.com/yui/folder/stream_file.php?doc_key=k9C2Uwcr44cRxCoB5hYp8Es3ZQD4l1C5v/GYieGLjow=
This version fixes a problem which could occur when a program using CLASSLIB was compiled (with the 'Abbreviate names' crunch option enabled).
Richard.
Re: Object Class library - CLASSLIB
Post by Andy Parkes on Jun 4th, 2014, 6:49pm
I have also updated CLASSLIBA (a slightly modified version of CLASSLIB) to incorporate Richard's update.
CLASSLIBA is not as compact as CLASSLIB, but makes it easier to work with object pointers and has some support for copy-constructors.
http://wiggio.com/yui/folder/stream_file.php?doc_key=9FxQglg4syu5W4KR1Ba3hJmesWrn4gNlSfm3IRi6p0g=
Andy
Re: Object Class library - CLASSLIB
Post by rtr on Jun 29th, 2014, 6:02pm
I have updated CLASSLIB to version 0.97. It may be downloaded from here:
http://wiggio.com/yui/folder/stream_file.php?doc_key=02xpBZzIzSxTR0U77TYmt6AI715/o5ro7AZAIMUrFNI=
This version fixes a serious memory leak which could occur when a class contains a string member variable.
Richard.