-----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.
