Greedo

i.e. sprinkled throughout

e.g. It looks like RD often uses a lightweight wrapper class to add logging to the forwarded methods of some wrapped class. So the functional code is not polluted with log messages, and it is easy to remove the logging layer entirely. However I cannot tell the logic of when a class has a log wrapper vs when no logs are needed. Also for trace logs of internal implementation details of a class, I can't see how a wrapper would capture this, so maybe those log calls are less OOP more procedural

@MathieuGuindon Thanks I'll definitely take a look. Although the framework isn't too important to me, the functionality I would imagine is pretty similar whatever the framework (please correct me). I'm asking what your advice is on when to Log. E.g. if a theoretical RD3 VBE addin written in tB were to depend on my code (directly or forked or copy-paste I have grand ambitions), how would it like the logging interface to look? Should it even have logs?

Matt wrote an article on ambient context I should probably reread that. But maybe logging which exposes private implementation details of a package is TMI. On the other hand it can "empower" consumers of the package to trace bugs or provide logs back to me so maybe it's useful.

Typing is hard...

*any payment app = any parent app

*logging granaries wtf autocorrect I meant logging framework

*how do you advise doing logging

In other words; logging is one of the public interface of my program so should also be designed carefully.

Let's assume you have a great logging framework so any payment app that references your package can inject its own logger to configure behaviour of the logging (e.g. direct it to a file)

How do fit advise doing logging? In vbInvoke I have used your logging granaries @MathieuGuindon for VBA I think I tidied it up a bit maybe and made a tB package. But I've got all this logging everywhere which is very useful to debug. I thought I could add a LogManager that implements the right interfaces but all the methods are NOOP. That would remove pretty much any performance overhead I imagine. But I'm wondering about your (plural) advice on when to include logging in a release of a package

@this This is not a fundamental restriction with using private ITypeInfo then, just a blocker to the current implementation of RD?

@this github.com/fafalone/tbShellLib/blob/… Yes perfect

@this That makes sense, similar to persisting a VBA Class over a stop button press using AppDomain, all bets are off on whether it remains valid. There are probably implementation detailsy instances where caching is possible. But TBH reading the structs is pretty instant, it's at the RD level where caching can be done - request the ITypeInfo of only the dirty modules, never save the object. Perhaps I could serialise the ITypeInfo and never expose the object directly...

@this Yeah I actually meant does anyone have VB6 stub declarations for the ITypeInfo/ITypeLib/FUNCDESC etc. methods and objects so I can have a start point to declare the interfaces in tB. Agreed the helper methods in TLI aren't the best API.

As in, maybe the ITypeInfo I get in vbInvoke is not the one you will need. I vaguely seem to remember it not containing Enums or Types or something along those lines

Also I read in RD code somewhere, I think in the IVBComponent interface, there are "pointers to some related typelibs"... Anyone know if the invocation type information is the same as the stuff RD would require for identifier resolution

@this you said something about not being able to cache them?

Is it worth me exposing that type info in my vbInvoke code do you think? Does anyone have VB6 declarations for TLI it's a bit fiddly to get them all and test thoroughly.

So the ModuleAccesor code naturally generates ITypeLibs/ ITypeInfo for any modules and projects loaded in the VBE. There was discussion around RD using this to resolve identifiers that point to password protected addins. Is that the idea?

*interesting = relative to other licenses, but dull as dishwater in absolute terms ;)

IIUC :D

The spirit is, if Big Company uses your library, any improvements they make must be made open source, but if it's just used as a component of their product they don't need to make the entire product open source or under the same license, only the bits that came from your library.

Mozilla Public License 2.0 and LGPL look interesting, they force you to distribute source code of the licensed work and disclose source code of any modifications you make to the files in it. And those modified versions must also have the same license or stricter. However the wider project (e.g. one which imports your code) does not need to have any specific license.

@M.Doerner practically I think whatever license I pick is likely to be a non-issue unless the package becomes really popular. But I could ping Wayne

Yeah GPL has some "at arm's length" exceptions - this is how proprietary software like Windows OS can run GPL exes. So with the RD3 split maybe something like GPL for the Language Server that uses the Grammar, but the LSP-client (dev tool) communicates at arm's length using the protocol so could have a different license. Basically could RDE load fine without RD LSP, yes. That's my impression and probably in the spirit of Antlr's license - they don't care about VBE addins, just parsers

Thanks I think it is a grey area translating and also I wasn't even translating because VBA doesn't have half the stuff C# does so it was more a process of understanding the technique then re-implementing from scratch.

@MathieuGuindon This is cool though :)

It's a tricky balance. I think if it was just GPL derivatives must be Open Source then you could make GPL -> Public Domain Dedication -> Closed Source very easily with the Public Domain package just importing the GPL package and exporting it again. Easy to game it.

If they're not willing to go open source. TBH it's still a bit over my head

Which reduces your reach

Well it's not such a bad one, I guess it stops business users from building on it

ooops

I forgot RD would have its own dependencies

Oh lol, it's a virus then

Now if anyone uses my package they have to use it too

I didn't think it would. But you chose GPL 3 for a reason. It's nice to see it spreading.

Now though I've been reading up on Licenses, I'm pretty sure even though the VBA I wrote isn't a direct translation of c# but more just inspired by it, vbInvoke would still be considered a derived work of RD. Which means I have to use GPL-3 right?

License question: I made that VBA a while back which ported the RD test execution, and then ported that to tB to make github.com/Greedquest/vbInvoke. Now I released that in MIT license because that's the default that gets added to a project when you save as a .twinpack and I didn't think much of it.

@MathieuGuindon C# can really do a lot of stuff VBA can't... That's all contestants basically, but generated dynamically at compile (design?) time

you forgot about naming stuff

*top 3

Was skipping first typelib, which didn't matter except in this edge case

Off by one error

Fixed it 🎉

(backup work before attempting)

@MathieuGuindon Thanks:) Required quite a bit of VTable hacking to get the interface like that, probably a bit fragile

v1.0.1 you get the vbInvoke_win64.dll and you can add reference to it in VBA. Then you'll see vbInvoke.GetExtendedModuleAccessor and vbInvoke.GetStandardModuleAccessor (public only)

Try it out if you want. github.com/Greedquest/vbInvoke/releases

Working for public and private methods. You can loop over all the methods in a module and call them with CallByName or `dot.notation. The method names are generated from the ITypeInfo directly