Truffle API feedback
Jaroslav Tulach
jaroslav.tulach at oracle.com
Tue Oct 20 17:42:24 UTC 2015
Hello Tim,
#5 and #6 are fixed. Please check the latest Javadoc: http://lafo.ssw.uni-linz.ac.at/javadoc/truffle/latest/
Please kemp reminding me about the rest.
-jt
Odesláno z iPadu
19. 6. 2015 v 18:59, Tim Boudreau <niftiness at gmail.com>:
> Hi, folks,
>
> I've been poking around randomly in the Truffle sources, and made a few
> notes on places where the API could be cleaner (which I think Jarda Tulach
> is actively working on):
>
> 1a. CompilerOptions.setOption(String name, Object value);
>
> would be easier to use if it returned CompilerOptions instead of void, so
> method chaining can be used. In general, any time something like this
> returns void, you're throwing away an opportunity to make calling code less
> verbose.
>
> 1b. A cleaner and safer pattern would be:
>
> public abstract class CompilerOption<T> {
> protected abstract void validate(T value) throws SomeException;
> //because you can
> }
>
> and
>
> <T> CompilerOptions.setOption(CompilerOption<T>, T value);
>
> and let people define static fields with CompilerOption instances.
>
> That would be typesafe and would eliminate typos in string names. And
> would probably allow language authors to factor their option processing
> more cleanly than a big switch statement.
>
> --------
>
> 2. CompilerDirectives.injectBranchProbability(double probability, boolean
> condition) and the constants such as LIKELY_PROBABILITY
>
> You're better off with a Probability class that hides the floating point.
> There's no particular reason this sort of computation needs to be floating
> point, and if it does, you're still better off with
> Probability.isMoreLikelyThan(otherProbability) or
> Probability.times(otherProbability).
>
> More flexibility later, you can put bounds on legal values (what would a
> probability of Float.MIN_VALUE mean? Make that impossible), and it's
> cleaner.
>
> --------
>
> 3. ReplaceObserver.nodeReplaced - observer/listener methods are clearer if
> named on$EVENT, e.g. onNodeReplaced - so if implemented as a mix-in, it is
> still obvious that this method responds to an event.
>
> Same for SourceListener, and probably other things named *Listener /
> *Observer.
>
> --------
>
> 4. Should TruffleOptions really have world-writable static fields?
>
> --------
>
> 5. BytesDecoder.decode() - should probably return CharSequence, not
> String. With CharSequence you keep the option of avoiding a memory copy,
> with an implementation of CharSequence over the raw array bytes.
>
> Once it's String, you can never go back. Same for Source.getCode().
>
> --------
>
> 6. Source.setFileCaching() - this does not look like it should be API.
> Maybe some attribute of whatever is using the Graal API on initialization
> (perhaps user code -> language -> truffle), but not here.
>
> --
> http://timboudreau.com
More information about the graal-dev
mailing list