Re: Jazoon Talks: I need feedback on titles/abstracts of my proposals

[Peter Arrenbrecht]

Jesse, thank you for taking such a detailed look!

On Thu, Dec 17, 2009 at 6:05 PM, Jesse Glick <Jesse...@sun.com> wrote:
> API tips:
>
> Parametrize by factory type to avoid casts, thus:
>
> EngineBuilder<RebateComputationFactory> builder =
> SpreadsheetCompiler.newEngineBuilder(RebateComputationFactory.class);
> builder.loadSpreadsheet(_sheetName);
> builder.bindAllByName();
> builder.failIfByNameBindingLeftNamedCellsUnbound();
> Engine<RebateComputationFactory> engine = builder.compile();
> RebateComputationFactory factory = engine.getComputationFactory();
> return factory;
>
> A fluent API can also avoid the need to type any angle brackets:
>
> return SpreadsheetCompiler.newEngineBuilder(RebateComputationFactory.class).
>    loadSpreadsheet(_sheetName).
>    bindAllByName().
>    failIfByNameBindingLeftNamedCellsUnbound().
>    compile().
>    getComputationFactory();

Ah, yes. We debated the genericity. And the added stutter bothered me
too much (yes, despite the bit of type-safety it adds). But your
excellent idea to get around this with a fluent API - and the
inference I think is slated for JDK7 - clinches it. We should do this
now.

> Also suggest avoiding String as a way of referring to files; can be unclear
> what exactly is meant. Absolute file path? Relative to some dir? Classpath
> entry? URLs accepted? Requiring e.g. java.io.File is clearer.

You might be right. Interestingly, this seems points to a cross
purpose of literate testing and API design. I did add the
string-taking load method to shorten the basic use case, including
line length, to make the citation super compact. Should not have
gotten carried away like that.

> Better not to invite trouble by making your Engine impl extend ClassLoader;
> sooner or later someone will rely on this despite your warning. Delegate to
> a private field.

Makes sense.

Again, many thanks,
-parren