[Libreoffice] concept for c++ based subsequenttests

[Bjoern Michaelsen]

Hi Kohei,

On Wed, Nov 30, 2011 at 05:35:33PM -0500, Kohei Yoshida wrote:
> Also, by "funky garbage collection" if you are referring to the
> ref-counted cssu::Reference memory management that UNO API uses (since C
> ++ doesn't even have memory management natively), doesn't python have
> the same issue since its objects are all reference-counted?  And since
> with python it has to go through the language binding wouldn't it make
> it even more interesting than native C++ binding?

No, I was refering to the fact that Java objects are _not_ refcounted and thus
sometimes can create interesting scenarios. Stephan likely can tell you a few
dark tales about Java zombie objects.

> Let's not read too much into my words.

Ok, lets just say the were very inviting to interpretation.
 
> So, who would be willing to invest time if it were written in python?
> With C++ at least Markus is already showing interest.

Well, so far we are not suggesting to newcomers comfortable in Python that we
have much to offer for them:

https://wiki.documentfoundation.org/Development/Easy_Hacks_by_required_Skill#Easy_Hacks_requiring_Python_Skills

OTOH I dont think it makes sense to have 50 tests in C++, 1 in StarBasic, 200
tests in Java and 5 in Python and be stuck with all of them. I was just
supporting Michaels point that having a quicker way than Java/C++ for tests
might be worth consideration(*). FWIW I used to start tests in StarBasic -- as
ugly as it is -- because a) it spares you the interface casting madness and b)
it provided reflection via DBG_properties, DBG_methods and
DBG_supportedInterfaces. And once the testcode was done, I rewrote the stuff in
Java (which was the only sensible option at the time).

Best,

Bjoern