On Sat, Mar 12, 2016 at 11:01 PM, Martin Grigorov <[email protected]>
wrote:

>
> On Sat, Mar 12, 2016 at 7:48 PM, Sven Meier <[email protected]> wrote:
>
>> Hi,
>>
>> 1)
>> we've been twiddling with read-only models for some time now, and IIRC it
>> never quite worked out.
>> I don't see much benefit in IReadOnlyModel as it is proposed now -
>> perhaps I'm missing the point though.
>>
>> How about adding another default to IModel:
>>
>>     default void setObject(final T object) {
>>         throw new UnsupportedOperationException();
>>     }
>>
>> This way we can get rid of AbstractReadOnlyModel too :P
>>
>
> A minor thing that bothers me here is that currently AROM#setObject() is
> final, so subclasses are effectively read only too.
> By moving this method to IModel we cannot make any guarantees.
> But I guess it will always be used as an anonymous inner class, as AROM is
> used now. If someone wants to have children then (s)he will have to create
> a custom class and there (s)he can make it 'final'.
> Let's do it!
>

As a bonus IModel is a @FunctionalInterface now and one can do things like:

new Link<String>("", () -> "abc") {
   @Override
   public void onClick()
   {
      // ...
   }
};


>
>
>>
>> 2)
>> I don't see a need for this.
>>
>> Have fun
>> Sven
>>
>>
>> how about adding a
>>
>>
>> On 11.03.2016 22:54, Martin Grigorov wrote:
>>
>>> Hi,
>>>
>>> At "lambdas" [1] branch there are two more features:
>>>
>>> 1) IReadOnlyModel by Michael Mossman
>>>
>>> At the moment there are AbstractReadOnlyModel and SupplierModel (extends
>>> from AROM).
>>> Initially while MM suggested IROM I thought it will be a parent interface
>>> of IModel but it is the opposite - IROM extends from IModel.
>>> I don't see need of IROM. The classes look enough to me.
>>>
>>> 2) stream based iteration of container's children by Andrea Del Bene
>>> I have said my opinion before - the visitor approach is faster than the
>>> stream based one.
>>> In addition we have to remove the deprecated
>>> org.apache.wicket.util.iterator.AbstractHierarchyIterator and its related
>>> classes because it fails with StackoverflowError when used in a page with
>>> bigger component tree.
>>> So I don't see a reason for this feature.
>>>
>>> Your option on them ?
>>>
>>> 1. https://github.com/apache/wicket/compare/lambdas
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>> https://twitter.com/mtgrigorov
>>>
>>>
>>
>

Reply via email to