Re: Changing the XProcStep interface?

  Hi Norm,

  Not sure you adopted this already or not, but just a few notes...
You refer to adding a static method to an interface.

1) This is new in Java 8 (not a problem per se, but might be a problem
for some users).

2) As far as I know, you need to give an implementation of such a
function (what would it mean for a static virtual method?), which does
not seem to be the case below.

3) As far as II know, it does not change the "interface" of the
interface (well, it adds a "class function", but does not requires
concrete classes implementing the interface to provide anything else
than they already do).

  Hope that helps.  Regards,

-- 
Florent Georges
http://fgeorges.org/
http://h2oconsulting.be/


On 20 April 2015 at 03:46, Norman Walsh wrote:
> Hello world,
>
> The XProcStep interface, com.xmlcalabash.core.XProcStep is:
>
> public interface XProcStep extends XProcRunnable {
>     public void setInput(String port, ReadablePipe pipe);
>     public void setOutput(String port, WritablePipe pipe);
>     public void setParameter(QName name, RuntimeValue value);
>     public void setParameter(String port, QName name, RuntimeValue value);
>     public void setOption(QName name, RuntimeValue value);
> }
>
> XProcRunnable is just reset() and run().
>
> I'm thinking of adding a static configureStep method:
>
>     public static void configureStep(XProcRuntime runtime);
>
> This would be called during configuration, before any pipelines have
> been parsed. I'm currently using it (through reflection, without
> changing the interface) to tinker with the URIResolver so that I can
> resolve step declarations without hitting the network.
>
> For example, in the next release of the cx:asciidoctor step, you'll
> be able to use
>
>   <p:import href="http://xmlcalabash.com/extension/steps/asciidoctor.xpl"/>
>
> And that will get the declaration for the cx:asciidoctor step, but it
> will never have to go to the network to get it.
>
> On the one hand, changing interfaces in Java is a real problem.
> Anything that uses that interface will have to be *recompiled*.
> There's a reason that the Java platform never allows java.* and
> javax.* packages to change an interface after it's published!
>
> And reflection works.
>
> On the other hand, reflection is a subversive and undocumented way to
> change an interface! I'd rather change it, but I don't have to, at
> least not in XMLCalabash1. I'm sure I'll do something different in
> XMLCalabash2.
>
> I think I've just about convinced myself not to change it, but since
> I've typed all this up, I guess I'll send it :-)
>
> Thoughts?
>
>                                         Be seeing you,
>                                           norm
>
> --
> Norman Walsh
> Lead Engineer
> MarkLogic Corporation
> Phone: +1 512 761 6676
> www.marklogic.com

Received on Wednesday, 6 May 2015 15:49:34 UTC