[pattern][lang] Calling thee, O Good Lords of Avalon...

[Ola Berg <ol...@arkitema.se>]

... please consider listen to an unworthy [common] low-life peasant:


>2. there are already projects in commons that define interfaces, like 
>commons-logging and commons-discovery, etc

I then request permission of you, mighty Masters, to use such interfaces of such great value without having to depend on the whole high-level package, if You don\'t mind.

>>�I personally think enums should be in collections - but in any case 
>>�as long as they are \'utils\' you use, not new interfaces ( Iterator is 
>>�just fine for interface ). I think commons is ok.

> +1

Sire, some of us unworthy peasants like to use enumerated types (like in C code of the Ancient Times), and therefore created an Enum class. I hope you don\'t mind the name resembling the ol\' iterator of arcane Java named \'Enumeration\', which as you so wisely pointed out, Honorable Knight, belongs in a collections package. 

>Not design patterns, but arbitrary interfaces and 
>then attempts to get people to use those interfaces - things like
>Factory, Identifier, Immutable, Identifiable, Command, Predicate, etc.
>They probably belong in avalon or another project, I personally don\'t 
>think commons is the right place. Sorry. 

Oh Sire, I hope we, low-level creatures as we are, did upset your feelings when we dare come up with such a bold proposal. It is just that the common interfaces we discuss already are in numerous of projects, among peasants that is, so we just thougth that we could help each other by sharing them. It is not much, we know, but a lowly peasant don\'t have a full blown frame-work at his hands. 

>AAAAgghhhhhh >:-O
>-1000000000000
>You want to put Avalon in commons!

Excuse me Sire, don\'t kill me, please don\'t kill me! I forgot that You, knights of Avalon have total monopoly on object life cycle methods and that no other mechanism of object configuration, object recycling, object identification, object pooling, object transformation object foobarilaization are tolerated in this great country of yours. 

As the charter clearly states at jakarta.apache.org:

\"Life cycle mechanisms belong in Avalon and Avalon only. If you want to do component life cycle management, do it the Avalon way, using the Avalon classes or don\'t. There will never be another component framework or part thereof on this part of the Earth than Microsof.. I mean Avalon\"

/O
(who actually likes Avalon)
----
ola.berg@arkitema.se
0733 - 99 99 17

--------------------
ola.berg@arkitema.se
0733 - 99 99 17
www.arkitema.se

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [pattern][lang] Calling thee, O Good Lords of Avalon...

[Berin Loritsch <bl...@apache.org>]

> From: ola.berg@arkitema.se [mailto:ola.berg@arkitema.se] 
> 
> ... please consider listen to an unworthy [common] low-life peasant:


LOL!  ;P

You really think we're that stuck up?


> >2. there are already projects in commons that define interfaces, like
> >commons-logging and commons-discovery, etc
> 
> I then request permission of you, mighty Masters, to use such 
> interfaces of such great value without having to depend on 
> the whole high-level package, if You don\'t mind.

How is this directed to the "Good Lords of Avalon"?


> >> I personally think enums should be in collections - but in any case
> >> as long as they are \'utils\' you use, not new interfaces 
> ( Iterator is 
> >> just fine for interface ). I think commons is ok.
> 
> > +1
> 
> Sire, some of us unworthy peasants like to use enumerated 
> types (like in C code of the Ancient Times), and therefore 
> created an Enum class. I hope you don\'t mind the name 
> resembling the ol\' iterator of arcane Java named 
> \'Enumeration\', which as you so wisely pointed out, 
> Honorable Knight, belongs in a collections package. 

Probably true.


> >Not design patterns, but arbitrary interfaces and
> >then attempts to get people to use those interfaces - things like
> >Factory, Identifier, Immutable, Identifiable, Command, 
> Predicate, etc.
> >They probably belong in avalon or another project, I 
> personally don\'t 
> >think commons is the right place. Sorry. 
> 
> Oh Sire, I hope we, low-level creatures as we are, did upset 
> your feelings when we dare come up with such a bold proposal. 
> It is just that the common interfaces we discuss already are 
> in numerous of projects, among peasants that is, so we just 
> thougth that we could help each other by sharing them. It is 
> not much, we know, but a lowly peasant don\'t have a full 
> blown frame-work at his hands. 

I need to go back and see who said it needs to be in Avalon.
I know I didn't....


> >AAAAgghhhhhh >:-O
> >-1000000000000
> >You want to put Avalon in commons!
> 
> Excuse me Sire, don\'t kill me, please don\'t kill me! I 
> forgot that You, knights of Avalon have total monopoly on 
> object life cycle methods and that no other mechanism of 
> object configuration, object recycling, object 
> identification, object pooling, object transformation object 
> foobarilaization are tolerated in this great country of yours. 
> 
> As the charter clearly states at jakarta.apache.org:
> 
> \"Life cycle mechanisms belong in Avalon and Avalon only. If 
> you want to do component life cycle management, do it the 
> Avalon way, using the Avalon classes or don\'t. There will 
> never be another component framework or part thereof on this 
> part of the Earth than Microsof.. I mean Avalon\"


Well, I do have to agree that Avalon does not belong in Commons,
but it should work *with* Commons as much as possible.  The commons
charter expressly forbids frameworks, which Avalon is definitely
a framework.  Its existence in Commons would break its high and
mighty charter ;P

Keep in mind also that the Avalon containers are converging on a
standard way of extending the default lifecycle.  Therefore, if
you want to totally ignore the Avalon lifecycle, and use your
own lifecycle, you can--and still take advantage of the hard
work us "knights of the roundtable" have provided for you.

> 
> /O
> (who actually likes Avalon)


You do?  Kool!


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>