Author |
Topic: Object Class library - CLASSLIB (Read 268 times) |
|
Andy Parkes
Developer
member is offline
Gender: 
Posts: 25
|
 |
Re: Object Class library - CLASSLIB
« Reply #9 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
|
|
 Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: Object Class library - CLASSLIB
« Reply #10 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.
|
| « Last Edit: Feb 10th, 2014, 9:49pm by admin » |
Logged
|
|
|
|
Andy Parkes
Developer
member is offline
Gender:
Posts: 25
|
|
Re: Object Class library - CLASSLIB
« Reply #11 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
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: Object Class library - CLASSLIB
« Reply #12 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.
|
|
Logged
|
|
|
|
Andy Parkes
Developer
member is offline
Gender:
Posts: 25
|
|
Re: Object Class library - CLASSLIB
« Reply #13 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
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: Object Class library - CLASSLIB
« Reply #14 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.
|
| « Last Edit: Feb 12th, 2014, 9:41pm by admin » |
Logged
|
|
|
|
Andy Parkes
Developer
member is offline
Gender:
Posts: 25
|
|
Re: Object Class library - CLASSLIB
« Reply #15 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
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: Object Class library - CLASSLIB
« Reply #16 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.
|
|
Logged
|
|
|
|
Andy Parkes
Developer
member is offline
Gender:
Posts: 25
|
|
Re: Object Class library - CLASSLIB
« Reply #17 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
|
|
Logged
|
|
|
|
Andy Parkes
Developer
member is offline
Gender:
Posts: 25
|
|
Re: Object Class library - CLASSLIB
« Reply #18 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
|
|
Logged
|
|
|
|
Andy Parkes
Developer
member is offline
Gender:
Posts: 25
|
|
Re: Object Class library - CLASSLIB
« Reply #19 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
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: Object Class library - CLASSLIB
« Reply #20 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.
|
|
Logged
|
|
|
|
Andy Parkes
Developer
member is offline
Gender:
Posts: 25
|
|
Re: Object Class library - CLASSLIB
« Reply #21 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
|
|
Logged
|
|
|
|
|
