#ifdef #101

Open
nicholas22 opened this Issue Jul 17, 2012 · 4 comments

Comments

Projects
None yet
2 participants
Collaborator

nicholas22 commented Jul 17, 2012

I was giving an intro to someone about how lombok works and their first expectation was, being a pre-processor of sorts, that it would have #ifdef/#ifndef, #endif and other such constructs. I am aware that one of the limitations with what we can do is that the source must not have Java syntax errors (hence the traditional #ifdef syntax is probably out the window), but it would be a nice addition if we could figure out a way how to do it.

Owner

peichhorn commented Jul 17, 2012

I was giving an intro to someone about how lombok works and their first expectation was, being a pre-processor of sorts, [...]

Yeah, there are similarities. ;)

[...] that it would have #ifdef/#ifndef, #endif and other such constructs.

This is an interesting reaction.

I'm not a big fan of adding c-ish pre-processor commands like #ifdef/#ifndef, #endif to lombok-pg, since they are mainly used to have platform-specific sections of code. As you know, we don't have this problem in java and other modern languages, which run on VMs, since you write your code against one single, portable standard library.
I think a bit differently of #define, thought. One use-case of #define was to inline methods, because c did not have inline functions prior to 1999. So you wrote your own macros and everything was golden. But even with inline fuctions there are still some other use-case today, where I still like to use macros, when working in c.

So what I take with me from you suggestion is, that it would be interesting, if users where able to define their own lombok extensions with some kind of template-scripting-mechanism.

This is not the first time, that this idea came to my attention. The lombok guys have started working towards something like that, with their lombok.ast project. But I'm pretty sure there still a boat load of work, till they can show anything that works decent enough.

I'm not going to start working on a template-scripting-mechanism for lombok-pg. This is the kind of hell, I don't want to enter. I'd rather create my own language. xD

Collaborator

nicholas22 commented Jul 18, 2012

"...we don't have this problem in java and other modern languages, which run on VMs, since you write your code against one single, portable standard library."

Are you sure? There are platform specific portions of code in Java as well. One example is the use of sun.misc.Unsafe. There are other examples, around file-specific constructs. I wouldn't suggest to create a new template scripting mechanism, just eliminate portions of code depending if a variable is true/false...

Owner

peichhorn commented Jul 18, 2012

Alright if include native methods calls it is possible to have platform specific portions of code. Good point! ;)
But then you 'just' have to run your code with the platform specific runtime libraries.

Let's assume that you need different native method calls for different platforms, don't you think it is cleaner, to put these peaces of code into different objects, using for example the strategy pattern?

Just to clarify I'm not totally against this feature. If lombok-pg can reduce code in this area I'm more than happy to give it a try. But for now I really don't see a use-case here, where lombok-pg would be a big benefit. Maybe you can shed some light on this for me.

Collaborator

nicholas22 commented Jul 18, 2012

The difference between pre-processor definitions and the strategy pattern is the point/time of execution. So with the former, we eliminate code completely: no overhead, no evaluation, nothing. With the latter, we are using virtual method dispatch. This may be a trivial difference for 95% of the code written, but not trivial if performance is of very high importance... Think for example of very tight loops where profiling code is injected. Avoiding the lookup of a variable may be very cost effective when the method is called thousands of times per second.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment