El vie, 07-04-2006 a las 13:30 +0200, Andreas Hartmann escribió:
> Thorsten Scherler wrote:
> > El jue, 06-04-2006 a las 17:40 +0200, Andreas Hartmann escribió:
> >> Hi Lenya devs,
> >>
> >> currently, it's not clear which classes+interfaces form
> >> the Lenya API (i.e., have to stay backwards compatible
> >> and therefore may be used by client code).
> >>
> >> Examples are AbstractUsecase and DocumentUsecase:
> >> Can you extend these classes without the danger of
> >> incompatible changes in future 1.4.x versions?
> >
> > I am unsure what to tell you. We have a couple of usecases that extend
> > this classes. IMO this default implementations should reflect the least
> > common denominator
>
> +1
>
> > and as soon as 1.4.x is in the release cycle they
> > *should* be backwards compatible.
>
> IMO AbstractUsecase and DocumentUsecase are general enough
> to put them into the API.
>
agreed, but we still would need an implementation right?
>
> >> I like the approach taken by Avalon/Excalibur:
> >>
> >> - framework/api/src/java
> >> - framework/api/src/test
> >> - framework/impl/src/java
> >> - framework/impl/src/test
> >>
> >> For example: AbstractLogEnabled is part of the API,
> >> AbstractConfiguration is not. A disadvantage of this
> >> approach is that you can't tell whether a class is
> >> part of the API without knowing where it is located
> >> in the source tree. Maybe we can solve this using
> >> package names which contain "impl":
> >>
> >> o.a.lenya.cms.usecase.*
> >> o.a.lenya.cms.usecase.impl.*
> >>
> >>
> >> Modules are another story, but maybe the same concept
> >> can be applied there.
> >>
> >>
> >> WDYT?
> >
> > Yeah, with this move we as well should harmonize the naming for the
> > implementation classes.
> >
> > We have now:
> > - Default{api-class-name}.java
> > - {api-class-name}Impl.java
>
> I'm using Default{*} if I want to point out explicitely
> that the class is just an example implementation, and
> {*}Impl if it is meant to be (more or less) the only
> implementation. But the differences are subtle, and
> it's fine with me to use only one naming convention.
>
Thanks for the explaning this, I always wondered. ;)
>
> > - {different-name-then-the-api-class-name}.java
> >
> > IMO if we agree on
> >> o.a.lenya.cms.usecase.*
> >> o.a.lenya.cms.usecase.impl.*
> >
> > Then we should have
> > - o.a.lenya.cms.usecase.*
> > * {api-class-name}.java
> > - o.a.lenya.cms.usecase.impl.*
> > * {api-class-name}.java
>
> IMO this is not very convenient, because you have to use
> explicit package declarations (which is quite verbose),
> and the class name references are ambiguous.
>
> For example:
>
> package org.apache.lenya.cms.impl.Document;
>
> class Document implements org.apache.lenya.cms.Document {
>
> public org.apache.lenya.cms.Document getParent() {
> ....
> org.apache.lenya.cms.Document doc = ...
> return doc;
> }
>
> }
>
> In other classes in the *.impl package you might want to
> access *.impl.Document instances directly (not via the
> interface), which is perfectly valid. IMO this makes the
> code hard to understand, because you always have to check
> the imports to know if it's an *.Document or *.impl.Document.
>
>
> I'd prefer
>
> - o.a.lenya.cms.usecase.*
> * {api-class-name}.java
> - o.a.lenya.cms.usecase.impl.*
> * {api-class-name}Impl.java
>
Makes perfect sense to me.
+1
>
> Thanks for your comments!
Thanks for bringing this up.
salu2
--
Thorsten Scherler
COO Spain
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
