Module "builders" to "extenders"

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Module "builders" to "extenders"

Andrus Adamchik
Just squeezed an 11th hour change before we freeze the Beta:

https://github.com/apache/cayenne/commit/175ec07f69446ea89c8ed8ec338b29d45f95821e
https://github.com/apache/cayenne/commit/ab6554dc6412dda640ebfcd6a4797cb0a1193f5f

The goal is to eliminate a new API inconsistency. With the introduction of auto-lodable modules, classes that we used to call FooModuleBuilder no longer build a FooModule. The module is loaded automatically and can not be changed. The corresponding "builder" builds a separate custom module with extensions. This pattern is present in:

1. CommitLogModuleBuilder
2. CacheInvalidationModuleBuilder
3. CryptoModuleBuilder
(4. OsgiModuleBuilder... if we make it auto-loadable)

Instead of a builder there's now an "extender", which is otherwise analogous to the builder, and the invocation looks like this:

  Module extensions =
     CommitLogModule.extend().addListener(mockListener).module();

I changed #1, and if there are no objections will change #2 and #3.

Andrus

Reply | Threaded
Open this post in threaded view
|

Re: Module "builders" to "extenders"

Hugi Thordarson
Is this correct module loading code for the New World Order?

b.addModule( CommitLogModule.extend().addListener( CommitListener.class ).module() );
b.addModule( CommitLogModule.extend().addListener( DictionaryListener.class ).module() );
b.addModule( CommitLogModule.extend().addListener( SearchIndexListener.class ).module() );
b.addModule( CommitLogModule.extend().addListener( PriceEventListener.class ).module() );

Cheers,
- hugi



> On 29 May 2017, at 15:04, Andrus Adamchik <[hidden email]> wrote:
>
> Just squeezed an 11th hour change before we freeze the Beta:
>
> https://github.com/apache/cayenne/commit/175ec07f69446ea89c8ed8ec338b29d45f95821e
> https://github.com/apache/cayenne/commit/ab6554dc6412dda640ebfcd6a4797cb0a1193f5f
>
> The goal is to eliminate a new API inconsistency. With the introduction of auto-lodable modules, classes that we used to call FooModuleBuilder no longer build a FooModule. The module is loaded automatically and can not be changed. The corresponding "builder" builds a separate custom module with extensions. This pattern is present in:
>
> 1. CommitLogModuleBuilder
> 2. CacheInvalidationModuleBuilder
> 3. CryptoModuleBuilder
> (4. OsgiModuleBuilder... if we make it auto-loadable)
>
> Instead of a builder there's now an "extender", which is otherwise analogous to the builder, and the invocation looks like this:
>
>  Module extensions =
>     CommitLogModule.extend().addListener(mockListener).module();
>
> I changed #1, and if there are no objections will change #2 and #3.
>
> Andrus
>

Reply | Threaded
Open this post in threaded view
|

Re: Module "builders" to "extenders"

Andrus Adamchik

Yes, but you can shorten it further:

b.addModule( CommitLogModule.extend()
  .addListener( CommitListener.class )
  .addListener( DictionaryListener.class )
  .addListener( SearchIndexListener.class )
  .addListener( PriceEventListener.class )
  .module() );

Andrus

> On May 29, 2017, at 6:38 PM, Hugi Thordarson <[hidden email]> wrote:
>
> Is this correct module loading code for the New World Order?
>
> b.addModule( CommitLogModule.extend().addListener( CommitListener.class ).module() );
> b.addModule( CommitLogModule.extend().addListener( DictionaryListener.class ).module() );
> b.addModule( CommitLogModule.extend().addListener( SearchIndexListener.class ).module() );
> b.addModule( CommitLogModule.extend().addListener( PriceEventListener.class ).module() );
>
> Cheers,
> - hugi
>
>
>
>> On 29 May 2017, at 15:04, Andrus Adamchik <[hidden email]> wrote:
>>
>> Just squeezed an 11th hour change before we freeze the Beta:
>>
>> https://github.com/apache/cayenne/commit/175ec07f69446ea89c8ed8ec338b29d45f95821e
>> https://github.com/apache/cayenne/commit/ab6554dc6412dda640ebfcd6a4797cb0a1193f5f
>>
>> The goal is to eliminate a new API inconsistency. With the introduction of auto-lodable modules, classes that we used to call FooModuleBuilder no longer build a FooModule. The module is loaded automatically and can not be changed. The corresponding "builder" builds a separate custom module with extensions. This pattern is present in:
>>
>> 1. CommitLogModuleBuilder
>> 2. CacheInvalidationModuleBuilder
>> 3. CryptoModuleBuilder
>> (4. OsgiModuleBuilder... if we make it auto-loadable)
>>
>> Instead of a builder there's now an "extender", which is otherwise analogous to the builder, and the invocation looks like this:
>>
>> Module extensions =
>>    CommitLogModule.extend().addListener(mockListener).module();
>>
>> I changed #1, and if there are no objections will change #2 and #3.
>>
>> Andrus
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Module "builders" to "extenders"

Hugi Thordarson
Ah, sweet—thanks :)

- hugi


> On 29 May 2017, at 17:52, Andrus Adamchik <[hidden email]> wrote:
>
>
> Yes, but you can shorten it further:
>
> b.addModule( CommitLogModule.extend()
>  .addListener( CommitListener.class )
>  .addListener( DictionaryListener.class )
>  .addListener( SearchIndexListener.class )
>  .addListener( PriceEventListener.class )
>  .module() );
>
> Andrus
>
>> On May 29, 2017, at 6:38 PM, Hugi Thordarson <[hidden email]> wrote:
>>
>> Is this correct module loading code for the New World Order?
>>
>> b.addModule( CommitLogModule.extend().addListener( CommitListener.class ).module() );
>> b.addModule( CommitLogModule.extend().addListener( DictionaryListener.class ).module() );
>> b.addModule( CommitLogModule.extend().addListener( SearchIndexListener.class ).module() );
>> b.addModule( CommitLogModule.extend().addListener( PriceEventListener.class ).module() );
>>
>> Cheers,
>> - hugi
>>
>>
>>
>>> On 29 May 2017, at 15:04, Andrus Adamchik <[hidden email]> wrote:
>>>
>>> Just squeezed an 11th hour change before we freeze the Beta:
>>>
>>> https://github.com/apache/cayenne/commit/175ec07f69446ea89c8ed8ec338b29d45f95821e
>>> https://github.com/apache/cayenne/commit/ab6554dc6412dda640ebfcd6a4797cb0a1193f5f
>>>
>>> The goal is to eliminate a new API inconsistency. With the introduction of auto-lodable modules, classes that we used to call FooModuleBuilder no longer build a FooModule. The module is loaded automatically and can not be changed. The corresponding "builder" builds a separate custom module with extensions. This pattern is present in:
>>>
>>> 1. CommitLogModuleBuilder
>>> 2. CacheInvalidationModuleBuilder
>>> 3. CryptoModuleBuilder
>>> (4. OsgiModuleBuilder... if we make it auto-loadable)
>>>
>>> Instead of a builder there's now an "extender", which is otherwise analogous to the builder, and the invocation looks like this:
>>>
>>> Module extensions =
>>>   CommitLogModule.extend().addListener(mockListener).module();
>>>
>>> I changed #1, and if there are no objections will change #2 and #3.
>>>
>>> Andrus
>>>
>>
>