Yes, that makes sense and I can see that in the documentation, but I can still see the utility in adding more granularity.
> -----Original Message----- > From: Scott Comer (sccomer) > Sent: Monday, February 09, 2009 1:20 PM > To: [email protected] > Subject: Re: [jira] Created: (ETCH-60) Would be useful for an extra > what option that splits apart generating interfaces and their > supporting classes > > interface files are always generated (interface files being all > ephemeral files). -w can restrict those to server or client. -w can > also > be used to generate main or impl in addition. -w intf is ignored, since > intf is always on. -w all generates everything (impl, main, intf). > > if you already have main and impl files, they won't be overwritten > unless you use -w force. > > scott out > > Rick Bolkey (rbolkey) wrote: > > I'm just referring to the ephemeral files---being able to generate > interfaces and plumbing files (Base*, Remote*, Stub*, ValueFactory*) as > separate compiler steps (I thought the INTF what compiler option would > do this, but it doesn't). > > > > > > Motivations (these are very java specific, but I'm sure there are > analogies in other languages): > > > > 1) Many projects provide separate reference API (interfaces) and > implementation (stub* et al) packages to provide flexibility in > implementation details or to hide the implementation detail (forcing > people to program to interfaces). > > > this is not supported for etch. > > 2) Assuming you should program to interfaces, they serve as the > public API, and are useful independently for testing by creating mock > objects through libraries like EasyMock or Mockito. > > > this is not always possible with etch, since some functions are only > available via the actual objects (_async, _transportBlah). but still, > programming to interfaces is good and that why etch generates separate > interfaces vs. remote, base, or impls. > > 3) My specific case, I have a service consisting of a number of mixin > services, and each is in their own package. For testing, I was > considering a separate package to launch the listener for each module. > Obviously, that launcher needs the entire binding for the service and > mixins. So I ended up with a cycle .... mixins require launcher (for > testing) requires service (for full binding api) requires mixins (for > implementation). One way to break the cycle is to split the binding as > a separate package, which leads back to motivation (1) above. > > > this explanation doesn't help me. if you've mixed in a bunch of stuff, > you only start the listener (for the top level guy) once. you don't > start listeners for the mixed in guys. > > So, this isn't a road blocker (thus minor priority), but I foresee > developers wanting this flexibility. > > > > > >> -----Original Message----- > >> From: Scott Comer (sccomer) > >> Sent: Monday, February 09, 2009 8:06 AM > >> To: [email protected] > >> Subject: Re: [jira] Created: (ETCH-60) Would be useful for an extra > >> what option that splits apart generating interfaces and their > >> supporting classes > >> > >> not entirely sure what you mean. please explain perhaps with an > >> example. > >> > >> etch compiler will already target generated ephemeral files to one > >> directory while user editable files go to another. > >> > >> Richard Bolkey (JIRA) wrote: > >> > >>> Would be useful for an extra what option that splits apart > generating > >>> > >> interfaces and their supporting classes > >> > >>> ------------------------------------------------------------------- > -- > >>> > >> ---------------------------------------- > >> > >>> Key: ETCH-60 > >>> URL: https://issues.apache.org/jira/browse/ETCH-60 > >>> Project: Etch > >>> Issue Type: Improvement > >>> Components: compiler > >>> Affects Versions: 1.0.1, 1.0.0, 1.0.2 > >>> Reporter: Richard Bolkey > >>> Priority: Minor > >>> > >>> > >>> A what option on the compiler that could tell languages that > support > >>> > >> interfaces to only generate the interface files or only the > >> implementation files would be helpful for separating those files > into > >> different packages or creating mocks from the interfaces. > >> > >>> > > > >
