Hi Andreas,
sorry for this delayed reply, but last days I was in vacation.
Alle 11:14, giovedì 4 agosto 2005, Andreas Bregas ha scritto:
[...]
> Does the problem only occur if you call CommandButton1_onAction()
> via a command button event? I assume it would be the same if you
> started a sub calling GetFolderName() directly.
yes, of course.
[....]
> > I guess that now (ooo 2.0) , when you call a routine from another one,
> > the basic interpreter search the matching routine in this order:
> >
> > 1. current module
> > 2. other modules in the current library
> > 3. other libraries at shared level (only if already loaded)
> > 4. other libraries at user level (only if already loaded)
> >
> > Is this correct?
> > If yes, I would ask why is the shared level checked before the user
> > level? And In wich order are checked libraries (and modules)? by
> > name ?
>
> 1. and 2. is correct, 3. and 4. not. Internally Basic makes no dif-
[... nice explanation snipped ...]
Thank you for the detailed information given!
> > A part from this, I would like to hear some opinions about the current
> > StarBasic's scope model:
> >
> > The main problem I see is that currently the macro developer has no
> > control over the name space in which his macro will run.
>
> There are no name spaces at all. Everything is global.
... and globalization, you know, has its own side effects ... :-)
seriously...
This is the fundamental point, obvious
see my comments below
>
> > Infact, although you can load external libraries from your macro program,
> > you cannot avoid to have unnecessary libraries already loaded, and this
> > can potentially raise problems, as in my demo code.
>
> What do you mean by "unneccary libraries"? Nobody is forced to
> load a library he doesn't need.
sure, but the end user can load libraries by executing macros.
For example, if
1) the end user launch from menu "file->wizards->euro converter"
and in the same OOo session but successively
2) the end user launch YOUR package
you will find that the libraries "Euro" and "Tools" will be already loaded.
This obviously implies that, all global/public variables and routines and
functions contained in those libraries will be in the same name space in which
your macro will run.
> And the xray library will not
> be loaded before used. But you probably mean that you cannot
> unload a library? That's true. Maybe we need a mechanism to
> reset Basic.
I'm thinking to something different (see my comments at the end of the post)
Anyway, IMHO such a mechanism could have some weird effect in some special
situations.
For example:
scenario:
a UNO-package with a single basic library and a single module, with the
following code:
REM ***** BASIC *****
Global oDoc
Global oDocView
Global oListener
Sub Main()
'....
REM register a selection change listener for the current document
oListener = _
createUnoListener("Doc_","com.sun.star.view.XSelectionChangeListener")
oDocView.addSelectionChangeListener(oListener)
'....
End Sub
REM event handlers
Sub Doc_selectionChanged(oEvent)
'do something useful here
End Sub
Sub Doc_disposing(oEvent)
'nothing to do
End Sub
When the sub Main ends, the control is passed to the listener, that will
call-back the sub MyDoc_selectionChange() everytime that the selection will
change.
Notice that between two call-back the end-user can of course launch other
macros, for example a thirdy-part UNO-package.
What happen to my global variables if the thirdy-part UNO-package resets the
runtime environment?
Notice that one could imagine also a more complicated scenario in which the
event-handler calls an external library (initially loaded in the Sub Main)
If this external library could be unloaded, the next call-back will end with
an runtime error: "sub-procedure or function-procedure not defined"
> > Yes, a possible workaround would be to use fully qualified calls (e.g.
> > Tools.ModuleControls.GetFolderName(...) )
> >
> > BUT
> > 1) "fully qualified" calls are ugly and they sound not very basic-ish
> > :-) 2) nobody really uses this workaround
> > 3) what about confilcts between global / public variables (or constants)?
> > is the "fully qualified call" applyable to variables too? (i guess no)
>
> Now we really run into target conflicts. You don't want to use
> fully qualified calls giving you full control as they are not
> Basic like but nevertheless you want to have full control. That
> sounds contradictory... :-)
You're right...I must agree.. :-)
> You're right with 2) but this would
> be true for every new concept we may implement to solve this
> problem. E.g. I could imagine to have a "private" library mode
> that make libraries only search inside there own scope and not
> searchable from outside.
[....]
Very very intersting.
Looking to the keywords used in variable declarations
Private
Public
Global
...and looking to the hierarchical organization of the code:
Module
Library
All libraries (LibraryContainer)
My impression is that the StarBasic name space was initially conceived with a
"private" library mode, but for some reasons it was implemented in a
different way.
This is only my idea, not based on any clue or "evidence" but looking at
this:
Private -> Module level
Public -> Library level
Global -> All libraries level
It would seem really perfect! :-)
> > is the "fully qualified call" applyable to variables too? (i guess no)
> 3) No difference to subs/functions. Example:
[....]
Thank you!, I must admit that I did not know this.
I was convinced that in difference to sub/functions, variables were not
callable with full pathname.
My mistake, sorry
> I'm not sure how problems like this can be solved in general.
> Any ideas are welcome. But there will alway be a target con-
> flict between "easy to use" and "full control".
First of all, I would say that I perfectly recognize that name conflicts as
the one I described are NOT a bug or a problem, but simply a normal
behavior:
Macro developers should be aware on the fact that when calling external
functions/variables, conflicts are possible and should be avoided using
fully-qualified calls.
So I can't find nothing wrong in the current name-space concept
That said, I think anyway that some "criticism" could be raised:
1)
The equivalence between
"load a library in the IDE" <=> "load a library by code"
appears strange.
The two concepts are not necessarily binded together. (IMHO they shouldn't)
I don't know any other language/IDE in which this equivalence does apply.
In my experience, I noticed that is really difficult to explain the scope
concept and the code organization to newbies.
IMHO the concept of "library loaded" is one of the things that makes newbies
confused.
2)
From the macro-developer point of view, a single global name space makes no
sense.
Nobody wants really share in the whole global space his public variables or
routines.
Infact, when a developer declares a public variable, in almost cases he only
wants to share the variable at Library level (in the same library in which
the variable has been declared)
In a few cases he may want to share the variable at "project" level.
But in no cases he really wants to share the variable in the whole global
space.
So, from the macro developer point of view this is only an unwanted side
effect
Just above I mentioned the word "project":
unfortunately, in StarBasic scope concept there's no a "project" level but
anyway, for "project" I mean a macro program that involves one or more
libraries.
Something in the middle between a single library and the whole global
container :-)
3)
There's no way to restrict the scope for routines. (sub and funtion)
This should be matter of the IZ 25885, but it seems that this issue is more
related with the appearance of the UI.
so let me add just a note:
In VB you can declare a routine as Private (module level) and I think it would
be useful in SB too, because conflicts are still possible.
**************
All that said, I clearly understand that anything I could suggest will appear
too problematic and risky (for compatibility), anyway here is my wish
list :-)
P1)
Introduce the concept of "private library mode"
A variable declared as Public should be viewed only inside the same library
and NOT from outside
The same should apply to Constants, (for Subs and Functions see below)
The Global keyword could preserve the current meaning.
P2)
Support of the Public / Private keywords for Functions and Subs
Calling a sub declared as Private from another module should raise an error
"sub or function not found"
A Sub or Function declared as Public should be visible only inside its own
library (accordig with P1)
P3)
Introduce a new Option in order to import a library in the name space
Something like this
Option Import LibName
All Variable/Const/Sub/Functions declared as Public in the Imported library(s)
will be callable in the current library.
This option could call the usual method LoadLibrary behind the scene, but the
idea is to get a strong separation between "load for edit" and "load in the
runtime namespace" and furthermore, to get a separation between the
interpreter and the API.
Currently we have the NameSpace controlled by some API calls (LoadLibrary,
IsLibraryLoaded etc)
IMHO the Basic Interpreter should be the only responsible of the management of
the namespace and the runtime environment, API Calls should be useful for
controlling the IDE (for example to edit automatically the code) but not for
a low level interaction with RT Environment.
To guarantee backward compatibility a further option should be introduced,
something like
Option OldScopeBehaviour
Ok, those are more or less my ideas :-)
Please, note that I'm not polemic or complaining for anything, I like
StarBasic and I'm using it daily from a lot of time.
I really appreciate your effort in developing and enhance the StarBasic engine
(BTW I'm testing the new "For Each" feature!! Great!!!... :-)
As I said before, I recognize that most probably none of my ideas can be
really considered, but I'm not a professional developer and simply I have no
idea of how much is difficult to manage a huge piece of code like the
StarBasic interpreter.
Another question where I have no clue is if my ideas fits the original "design
goals" of StarBasic.
Unfortunately StarBasic doesn't have its own project (no more) and it is
difficult to guess its specific "design goals" or a specific codeline ("where
are we going?") in the huge sea of the UDK project, but this is really
another story...
Anyway, this discussion is very intersting for me and I'm really happy to
share my thoughts here.
Thank you
Paolo Mantovani
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
