Surge: Platform specific code.

[jarkk0sakkinen]

If you have a class Foo, would be good if the common code would be in Foo.cpp and macOS specific code in FooMac.cpp. Sometimes even having some redundancy (e.g. some platform specific functions have partly the same implementations) is better than the compilation flag porridge inside the source files.

You would place these platform specific files to their own subdirections e.g. `src/common/mac' so that they are easy to manage from premake.

This has been motivated by seeing lots of Cocoa-specific code lying around. Doing this will also help to create new ports of Surge because by looking at what is inside a platform directory you will immediately know what you need to do in order to get Surge run.

[jarkk0sakkinen]

This will also help me with the standalone app effort.

[jarkk0sakkinen]

And not sure how much Cocoa-code has landed but just skimming through the issues.

[jarkk0sakkinen]

In order to keep headers out of platform specific cruft you can do something like;

private:
// Common variables
class FooImplementation *m_impl;

And then provide declaration in lets say FooMac.cpp for class FooImplementation.

[baconpaul]

Curious where you see cocoa specific code outside of src/au or src/mac? Is it just the ifdef Mac copying stuff for resources?

I like code separation but a separate class isn’t always possible without loads of copy and paste right? But I agree aspiring to have Mac and windows and Linux specific stuff cleanly segregated would be great.

[jarkk0sakkinen]

I saw the issue about the zooming code. I'm not speaking about separate class but more like that you have a set of functions in class where FooMac.cpp provides mac specific implementations of some of the functions. Not like there would be class FooMac. Then you can easily compile in those source files for mac.

[jarkk0sakkinen]

Like in the Linux kernel we have a declaration in a header of some function and depending on arch you compile in a different C-files, nothing more special than that.

[jarkk0sakkinen]

In some cases you can probably encapsulate the platform specific part into a separate function and let the master function to call it as part of its implementation.

[baconpaul]

Right - so take a look at the zooming code.

In src/common there is no cocoa code. I register a std::function as a callback and then in the au later implement that callback.

Is there something about the actual zooming code which is cocoa specific in the main branch? I designed and implemented it to be the exact opposite.

[jarkk0sakkinen]

Ah, you're right. Yeah, did not try to make a statement about Cocoa code specifically nor zooming code in particular but you are absolutely correct.

[baconpaul]

Cool!

So tell you what we can just check this when we review prs together and I agree we should aspire to this type of separation unless there is a “good reason” not to.

And since it seems we agree and there’s no code to fix right now, can we close the ticket?

And thanks for pushing for quality code!

[jarkk0sakkinen]

Yeah, maybe there was a slight misunderstanding. I'm more used to open source projects where a mailing list is the primary platform, not that much a Github person :) We can close this ticket. The point was to present an idea :)

[baconpaul]

And a good idea it was!

I suppose having a mailing list is something we should do. Or maybe a slack? I dunno - what do people use nowadays. But github tickets have worked well during our little 8 day burst of activity here.

[whydoubt]

There is an IRC channel on freenode: #surgesynth
However, without a logging bot, it's not good for conversations that you want to reference later or loop someone new into.
Never used Slack, but I have used gitter and discord.

[jarkk0sakkinen]

I think there is a logger bot service in Freenode. I can check!

[jarkk0sakkinen]

But neither IRC channel (nor Github) does really replicate benefits of the mailing lists.