expose virtual bool send(const TypeInfo*, const void* event) to allow customising type deduction about cppdap HOT 8 CLOSED

Hi @Coder666,

Exposing the raw-pointer API would be exposing quite a lot of private API functionality, which once made public, would need to remain public to avoid breaking backwards compatibility. The TypeInfo is considered mostly PIMPL, but at this point, is unlikely to change significantly.

So I'm a bit on the fence.

If we exposed the send method for events, we should also probably expose the send method for requests. For symmetry, we'd probably also want to expose the generic receive handler APIs too. That's quite a lot of new and complex API, and might be better done by breaking up the Session class into multiple components.

With all this said, I am confused why your IDebug interface is using DAP TypeInfo pointers. If the point of IDebug is to abstract the debug engine, why are you still depending on cppdap types?

Many thanks,
Ben

from cppdap.

Hi Ben,

My initial suggestion really derives from the fact that the "Impl" has been made private (at the source level) and also has been coupled to the "session::create" method, if that wasn't the case then I would have simply subclassed the Impl and exposed the functionality required.

A secondary suggestion would be to expose the factory to modification with appropriate default, for example:

class Session
{
public:
     typedef std::function< std::unique_ptr< Session >() > sessionFactory;
...
     // override the standard session create functionality
     static void setFactory( sessionFactory );
...
};

And then also expose the Impl by providing a header file with the definition.

This would then fit your requirement of leaving the send method hidden for most users, while also allowing anyone to subclass the Impl and make needed adjustments where required.

Cheers

Tom

from cppdap.

Hi Tom,
Thank you for the details.
I'm on vacation for the next couple of weeks. I'll try and get back to you soon, but it might take me a little while.
Cheers,
Ben

from cppdap.

No worries, enjoy your vacation.

from cppdap.

Hi again @Coder666,

Sorry it's taken me so long to get back to you here.

I'd like to understand the problem a bit more before considering exposing the guts of the Session as public API.
Based on the original posting, it sounds like IDebug is an abstraction over the debug engine, is that right?
If so, why would IDebug need to use cppdap reflection types?

Many thanks,
Ben

from cppdap.

Hi,

First of all, there is some coupling between dap and my application, I haven't abstracted it completely.

The dap types are used in their native form, however I have removed the direct adapter->session coupling so that session can essentially be "stripped" from the binary when debugging is not allowed by simply removing a single line of code, also facilitates interface mocking and testing allows us to say this is not debuggable by returning a NULL IDebug etc etc.

IDebug is a pure virtual interface:

class IDebug
{
public:
        virtual dap::ResponseOrError<dap::PauseResponse>                    OnPauseRequest                   (const dap::PauseRequest& request) = 0;
...
        virtual void                                                        SetEventSink                     (const std::function< void(const dap::TypeInfo* typeinfo, const void* event) >& eventSink) = 0;
... 
...
...
};

Virtual template functions are not a thing so adding a factory method would allow me to subclass the implementation and add custom functionality without breaking everyone elses code, i.e allow me to use the raw event sending function. For now I have just made this public in my code base.

from cppdap.

Thank you for the speedy response, Tom.

Would changing all the Session methods that are protected to public work for you?

from cppdap.

Hi Ben,

Yes that would work

Thanks

from cppdap.