cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Washeim <esa...@canuck.com>
Subject Re: [C2] Package names
Date Wed, 05 Jul 2000 14:51:01 GMT
on 4/7/00 6:39 pm, Stefano Mazzocchi at stefano@apache.org wrote:

> Mark Washeim wrote:
>> 
>> on 4/7/00 1:49 pm, Stefano Mazzocchi at stefano@apache.org wrote:
>> 
>>> Giacomo Pati wrote:
>>>> 
>>>> --- Niclas Hedhman <niclas@localbar.com> wrote:
>>>>> Niclas Hedhman wrote:
>>>>> 
>>>>>> In the sitemap proposal there are
>>>>>> 
>>>>>> org.apache.cocoon.matcher
>>>>>> org.apache.cocoon.transformer
>>>>>> org.apache.cocoon.chooser
>>>>>> org.apache.cocoon.serializer
>>>>>> 
>>>>>> but
>>>>>> org.apache.cocoon.generators
>>>>>> 
>>>>>> in pluralis...
>>>>>> Inconsistent. Personally I would prefer the pluralis (with s) on
all of
>>>>>> them, but I think all agree that mixing should not be used.
>>>>> 
>>>>> Personally I use another 'pattern'.
>>>>> 
>>>>> org.apache.cocoon.transformation
>>>>> org.apache.cocoon.generation
>>>>> :
>>>>> :
>>>>> 
>>>>> Since it will normally not only contain the "transformers", but also
>>>>> support classes, exceptions and so on.
>>>>> 
>>>>> Problem a bit with match and choose...
>>>> 
>>>> org.apache.cocoon.matching
>>>> org.apache.cocoon.choosing
>>>> 
>>>> I do like this argumentation for naming, too.
>>> 
>>> I do too.
>>> 
>>> I don't like
>>> 
>>> org.apache.cocoon.transformer.Transformer
>>> 
>>> it makes sense to have
>>> 
>>> org.apache.cocoon.[action].[actor]
>> 
>> This isn't correct, is it? it's package (containter) class, not abstraction
>> of type one and abstraction of type two????
>> 
>> After all, the actions in question could well use actors from quite
>> different packages, no?
>> 
>> 
>>> type of naming convention.
>>> 
>>> +1
>> 
>> Well, I disagree, on principal. Objects are not actions, in any case. They
>> encapsulate identity. Hence, are best named as nouns. I'm being a bit anal
>> about packages and objects, I know, and it makes little difference in
>> reality, but
>> 
>> Of course, transformation.ExplicitTransformation is fine (better than
>> transformer), but matching and choosing. Yech.
>> 
>> org.apache.cocoon.match.MatchThis
>> org.apache.cocoon.choose.ChooseThis
>> 
>> and shouldn't it be:
>> org.apache.cocoon.map.match.MatchThis
>> org.apache.cocoon.map.choose.ChooseThis
>> (or some such) . . .
>> 
>> just my two bits . . .
> 
> All right.
> 
> What a pain.
> 
> Let's summarize a little:
> 
> 1) the sitemap is composed by components. Components "act", so they are
> actors.
> 
> noun    |   action
> 
> generator -> generate
> transformer -> transform
> serializer -> serialize
> matcher -> matching
> chooser -> choosing

matcher -> match
chooser -> chose

sorry to be picky, I'm also in a hurry (eurofootball goes live with cocoon
tonight :) )


> Is it ok so far? Do you guys have any more suggestion?
> 
> 2) assuming the above is final, we have to place all these into
> packages. To reduce verbosity the package should not be verbose.
> 
> org.apache.cocoon.[package].[noun]
> 
> where
> 
> [noun] must be the name of the interface component
> 
> so we have to decide what to use for [package]
> 
> Proposals are
> 
> a) [noun] singular
> b) [noun] plural 
> c) [action] derived from [noun]
> 
> i.e.
> 
> a) org.apache.cocoon.generator.Generator
> b) org.apache.cocoon.generators.Generator
> c) org.apache.cocoon.generation.Generator

org.apache.cocoon.generator.PrDocumentGenerator
org.apache.cocoon.generator.HrDocumentGenerator

That's my preference.

> 
> 3) Another alternative is placing everything into the same package
> 
> org.apache.cocoon.components.xxx
> 
> where all components reside in the same package with no further
> subpackaging (to keep verbosity small).
> 
> What do you think?
 
> [please, let's settle this down quickly]

-- 
Mark (Poetaster) Washeim

'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.

Quem colorem habet sapientia?'

Evan S. Connell

 



Mime
View raw message