New way to modify nested uno structs in LibreOffice BASIC
Andrew Douglas Pitonyak
andrew at pitonyak.org
Thu Jul 5 08:09:31 PDT 2012
On 07/05/2012 04:22 AM, Noel Power wrote:
> On 05/07/12 02:47, Andrew Douglas Pitonyak wrote:
>> On 07/04/2012 03:23 PM, Noel Power wrote:
>>> with
>>> http://cgit.freedesktop.org/libreoffice/core/commit/?id=1720641bf36306fc296635925e571556ced8a302
>>> a long standing wrinkle with modifying nested structs in basic
>>> should be eliminated
>>>
> [ blah blah blah ]
>> The behavior change scares me a bit. I seem to remember some time
>> back that there was a reason for this behavior, but I was given that
>> information many years back..... I discussed it in Berlin
> I'd be interested if you can recall
>> Do you intend to change UNO so that structures return as a reference
>> (very dangerous, don't do it), or only when used in basic as
>> object.structure.property? This may be workable / safe, but may break
>> some existing code (although I can't think of any code that it would
>> break).
> there is no change to uno only how basic handles an already acquired
> uno structure ( either one defined locally or fetched from some other
> uno operation )
>>
>> I feel silly asking this, since if you know how to change the
>> behavior, then you likely know more about this than I (I don't know
>> how to change the behavior).
>>
> being bitten ( often ) by changing basic I understand the fear :-)
> But, I can't see that this change would be 'dangerous' it surely is
> the correct and desired behaviour ( but maybe indeed I am missing
> something and perhaps influenced by a long irritation with the way it
> worked before ). Of course the caveat is there is always a risk of
> some unexpected side-effect with any change ( especially true in basic )
>
> Noel
The best that I can remember is that it is common to do things such as
initialize one structure from another. For example, set the value of the
top border to the value of the bottom border and then make some changes.
What if structures now copy by reference.... Consider this code:
Case 0:
tempBorder = table.topBorder
tempBorder.someValue = something
table.bottomBorder = tempBorder
At this point, the top and bottom border will be the same because they
reference the same object.
This is why I asked if the intention is to change the copy semantics, or
to simply change it so that in basic when you use
Case 1:
table.topBorder.someValue = something
THe example immediately above, is not likely to cause a problem, in
fact, it will probably eliminate bugs.
I expect that as long as copy by value semantics is retained apart from
use in a "dot" notation in basic, then something like this will still
work without introducing bugs
Case 2:
tempBorder = table.topBorder
If the code above causes tempBorder to reference the topBorder object in
the table, then there will likely be numerous bugs.
So, with your changes, how will it affect Case 0, Case 1, and Case 2?
I consider Case 0 and Case 2 the same. I believe that you are saying
that your change only affects Case 1, which will then work as expected
without changing case 0 / case 2.
I was probably exchanging email with Mathias Bauer, but was unable to
find the exchange. I did spend time looking for it.
--
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info: http://www.pitonyak.org/oo.php
More information about the LibreOffice
mailing list