Inline-Methods and Closure-Blocks

Yesterday, I had an idea for a new language feature (for Java of course). That is itself nothing special, as I like to think about those, however I believe this really stands out.

The main idea is to inline special methods, which can execute a (closure-)block into the lexical scope where is called.

What sounds really complicated, but in fact it is not. Inspired by the enhanced for-loop syntax, programmers should be familiar with everything after a short introduction. But before I repeat myself over and over, please have a look at the details at my blog or go straight to the Google Document.

  • I really believe in this idea, which is why I’d love to get as most feedback as possible. :slight_smile:

You get down and dirty pretty quick perhaps it’s useful to outline the real pain points first.

although i/o is very important, relative to a general purpose language it’s kinda niche(ok, that’s a bit over the top). I would advice to not leave it to the reader to pull this into(/apply it to) other area’s. Adding examples will allow the reader to get a better idea of(/ pin down) your suggestion and you get to test your construct.

//edited - improved some grammar / spelling

More indept, I usually favor words over characters(:%$#@) to indicate contructs unless they are natural (Math) or low profile(seperation char).

Yeah, baffles me slightly. Show us a few “problems” and how the new syntax proposes to make it look nicer.

Cas :slight_smile:

Thanks for answering!

@Mr_Light:
Interesting comment, I never thought it looks IO specific. I believe it has many interesting usages (please see the example below answering to princec)

Btw. I chose the character :’ to reuse the for (Object : Iterable it) syntax and ‘#’ because I’ not aware of conflicts and it looks like a macro, which is similar in functionality. However these are details, syntax may change.

@princec
I may refer to an example from Neal Gafter’s Blog. It’s about closures, but benefit is the same: Early exits from loops or recursive functions (in my case recursive inline-methods or those containing loops) without encoding it into return types or whatever.

thanks for listening :wink:

I can see where you got from and it makes sense. Thinking about it though I feel that in a method your working at a more micro level and a keyword wouldn’t hurt. but as you said thats quite missing the point to going on about it at this stage.

hmm I relatively new to the closure discussion, I saw some ppl lock horn’s and decided not to get involved till the dust settled. (well ok thats only part I simply didn’t have time 8)) So excuse my naiveness, but if you want to shortcircuit the search you basicly have meta data about the return value… conditions that yo don’t want to tie into your method. ‘There isn’t any’ is rewritten as ‘after checking all there is no positive match’ -> ‘searching yields no positive match’ The implementation of search should not be altered for reuse, preferably else make it receptable to reuse. (aparandly though a hook)

…I doubt you can see where I’m going so i’ll edit it when I’m at work, gotta run to catch the bus now though.

//edit
so ok I’m at work.

an early stop can only be applied to actions that have as a result a collection of things or can ‘run’ (numbers) If you can ‘hint’ that your only interested in a restrained result then the jvm can probebly be made smart enough to interpret and optimize it. Specifying the constraint is probably even less verbose then describing the logic to enforce it.

does that make any sense at all?

about the other point; it doesn’t look too IO specific but all the examples you gave are only applied to IO, yes Gafter’s Blog uses it in another context but also applies a different approach. It’s dangerous to refer to other sources or leave it to the reader, because it allows for different views, with subtle differences while everyone has the idea that everyone else has the same idea about it. By the time you have to actually specify it on paper(the specification) all hell breaks lose.

If you could get the syntax looking much less obscure I might think it’s a good idea but right now it looks like closures simply obfuscate the nice, simple, imperative style that made Java so nice and simple. I know people rave about them but I rather like to be able to understand what something does, and the order it does it in, at a glance, and those bits of code are anything but obvious.

Cas :slight_smile:

You never say precisely what the problem is you’re trying to solve.
You never say precisely how you’re fixing it.

I’m afraid that means you’re going to have a very hard time persuading people to your cause.

It did take me reading it a few times to get what it was about too, you really do go the wrong way about introducing the idea. Your problem is communication, if you can use a more commonly used word in place of a less commonly used one more often you are more likely to get your point across. Look at Sun’s text on the enhanced for-loop, simple English, and they also provide examples of the common approach to a particular problem alongside the approach with the new language feature.

You must also think about readability.