On 10 January 2011 15:51, Matt Benson <gudnabr...@gmail.com> wrote:
>
> On Jan 10, 2011, at 5:21 AM, Niall Pemberton wrote:
>
>> On Mon, Jan 10, 2011 at 3:27 AM, sebb <seb...@gmail.com> wrote:
>>> On 10 January 2011 00:26, Niall Pemberton <niall.pember...@gmail.com> wrote:
>>>> On Sun, Jan 9, 2011 at 11:21 PM, sebb <seb...@gmail.com> wrote:
>>>>> On 9 January 2011 22:46, Niall Pemberton <niall.pember...@gmail.com>
>>>>> wrote:
>>>>>> I would like to do a Lang 2.6 release. I have ported some of the
>>>>>> compatible changes from the trunk to the LANG_2_X branch - details in
>>>>>> the release notes:
>>>>>>
>>>>>> http://svn.apache.org/repos/asf/commons/proper/lang/branches/LANG_2_X/RELEASE-NOTES.txt
>>>>>>
>>>>>> The site is here:
>>>>>>
>>>>>> http://people.apache.org/~niallp/lang/
>>>>>>
>>>>>> Is there anything else anyone would like to include, or other
>>>>>> comments/opinions?
>>>>>
>>>>> Generally looks very good. A few minor points:
>>>>>
>>>>> Is the src/pending directory still useful, or could it be deleted?
>>>>
>>>> Its not been touched since 2005 so IMO we should remove it. It is also
>>>> still in the trunk, so I've removed it from the 2.x branch. If it
>>>> finds its way into the trunk then it could be considered for
>>>> back-poritng,
>>>>
>>>>> https://issues.apache.org/jira/browse/LANG-603 - I think we should
>>>>> remove - or implement - Cloneable
>>>>
>>>> Theres related discussion about this here:
>>>>
>>>> https://issues.apache.org/jira/browse/LANG-302
>>>>
>>>> We can't remove the interface because of backwards compatibility - so
>>>> its either do nothing or implement clone(). I have added my comments
>>>> to that ticket.
>>>
>>> +1 to implementing clone.
>>>
>>>>> ExtendedMessageFormat.setFormatByArgumentIndex
>>>>> and
>>>>> ExtendedMessageFormat.setFormatsByArgumentIndex
>>>>>
>>>>> both use the {...@inheritdoc} Javadoc tag - but there's nothing to
>>>>> inherit from. Either the tag should be removed, or maybe the method
>>>>> does not belong?
>>>>
>>>> Both those methods were added to java.text.MessageFormat in Java 1.4
>>>>
>>>> http://download.oracle.com/javase/1.5.0/docs/api/java/text/MessageFormat.html
>>>
>>> Looking again at the class, I see that all the set...Format() methods
>>> throw UnsupportedOperationException, so presumably the 1.4 methods are
>>> there to protect against write access to the superclass formats when
>>> running under 1.4+.
>>
>> There is a note in the ExtendedMessageFormat's class Javadocs of
>> regarding these:
>>
>> http://commons.apache.org/lang/api-2.5/org/apache/commons/lang/text/ExtendedMessageFormat.html
>>
>>> I think the Javadoc needs to be changed to clarify the behaviour (and
>>> remove the incorrect tags for 1.3).
>>> The other @inheritDoc tags work, but they don't apply either, because
>>> only the behaviour is deliberately different.
>>
>> Sounds good.
I've updated the Javadoc for the unsupported methods.
>>
>>> It's a pity that the class extends MessageFormat rather than using
>>> MessageFormat internally ("Favour composition over inheritance").
>>
>> Maybe, but one use case is where an API uses MessageFormat, then
>> ExtendedMessageFormat could be used as a drop-in replacement.
>
> This was indeed the reason for subclassing. It was a very deliberate choice
> as the whole endeavour would almost certainly have been less complicated
> using composition.
OK, understood. Thanks for the clarification.
> -Matt
>
>>
>> Niall
>>
>>> Perhaps we can fix that in 3.0?
>>> If not, at least we need to fix the same Javadoc in 3.0.
>>>
>>>> Niall
>>>>
>>>>>> Niall
>>>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
