Author |
Topic: Object Class library - CLASSLIB (Read 270 times) |
|
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
|
|
|
|
|
