Subject: RE: Script Library DUPLICATE problems! Help!!
If you prefer to write agents in Java, by all means do so. But I think there are some things you’re not realizing about LotusScript.
Here’s an example of a structure of script libraries such as you describe. There are no compile errors, and it works just fine:
Script Library: A
Option Public
Const ERR_OOPS = 21002
Function Pop
Msgbox "Pop!"
End Function
Script Library B
Option Public
Use “A”
Sub Be(x)
Pop
Print "Be " & x
End Sub
Script Library C
Option Public
Use “A”
Function See(ff As Integer) As Integer
Pop
See = ff + 7
End Function
Agent ABC
Option Public
Option Declare
Use “B”
Use “C”
Sub Initialize
Call Be(See(6))
Print ERR_OOPS
End Sub
Now, %Include doesn’t do anything that you couldn’t do with statements in the code. If you define a name in B, and you define the same name in C, then you’ll have a problem using B and C together in your agent. But if you define a name in A – as I have done – it’s available in B and C and in anything that “uses” them, no problem. LotusScript has no problem with your “using” A twice, indirectly – it realizes they are the same thing.
It only makes sense that LotusScript will complain in ABC if you define the same name in B and C, because then the name is ambiguous. When you refer to it, are you referring to the one in B, or the one in C? Yes, it would be nice if it recognized a Const as having the same value and didn’t bother to complain. But you can also use the Private keyword to keep things from escaping the scope of one library.
Java has a way to disambiguate matching names, because it forces you to create uniquely named classes to put everything into. There are no “naked” names as there are in LotusScript. But in LotusScript, it’s your choice whether to use classes. If you have functions with duplicate names in B and C, you could instead define them as members of differently named classes – then you could use the same name within the different classes, just like in Java. Don’t blame LotusScript for your bad choice of doing a non-object-oriented design!
I’m not saying that LotusScript is as nice a language as Java for OOP. I could list several annoying shortcomings off the top of my head, starting with the inability to create static methods and properties. But it is a quicker language to learn and, in my opinion, easier to use for simple tasks. It’s not nearly as bad as you seem to think; lots of high-quality production code has been written in LotusScript. I myself have written many script libraries which I reuse all the time – most of the good ones contain class definitions. So MODULAR REUSABILITY is by no means out of the question.
