You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Ash .." <eq...@hotmail.com> on 2003/11/30 11:15:47 UTC
[lang] StringUtils.subarray v/s subArray
Thanks for integrating the subarray implementation patch.
However, I am curious to know why Stephen chose to name the method
"subArray", in place of
"subarray".
In the English language, the prefix "sub" in this sense is joined to the
word with the resultant word being a single "token": subunit, subclass,
suburbs, subway... substring, subarray,
whereby, as per standard Java conventions, the name ought to be "subarray"
rather than "subArray".
Even names in Standard API reflect this: substring, etc.
thanks,
Ashwin
_________________________________________________________________
Tired of 56k? Get a FREE BT Broadband connection
http://www.msn.co.uk/specials/btbroadband
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] StringUtils.subarray v/s subArray
Posted by "Todd V. Jonker" <to...@consciouscode.com>.
I agree with Aswin. "substring" and "subset" are proper words and
therefore shouldn't have a capital in the middle. The coined term
"subarray" is a clear sibling with entirely analogous semantics, so it
should be treated as a single word. The capitalization of "subList"
sounds like it's out of standard.
.T.
On Sun, 30 Nov 2003 13:40:39 -0000, "Stephen Colebourne"
<sc...@btopenworld.com> said:
> I changed this based on subList() in the collections API. substring() is
> an
> alternative precedent, so I am open to opinions.
>
> Stephen
>
> ----- Original Message -----
> From: "Ash .." <eq...@hotmail.com>
> > Thanks for integrating the subarray implementation patch.
> >
> > However, I am curious to know why Stephen chose to name the method
> > "subArray", in place of
> > "subarray".
> > In the English language, the prefix "sub" in this sense is joined to the
> > word with the resultant word being a single "token": subunit, subclass,
> > suburbs, subway... substring, subarray,
> > whereby, as per standard Java conventions, the name ought to be "subarray"
> > rather than "subArray".
> > Even names in Standard API reflect this: substring, etc.
> >
> > thanks,
> > Ashwin
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] StringUtils.subarray v/s subArray
Posted by "Todd V. Jonker" <to...@consciouscode.com>.
On Sun, 30 Nov 2003 12:33:40 -0800, "__matthewHawthorne"
<ma...@phreaker.net> said:
> It seems to depend on whether we see the word "array" as a proper noun.
>
> java.lang.String has both substring and subSequence. There seem to be
> inconsistencies everywhere.
>
> I vote for subArray, since I would define a classname as being a proper
> noun.
But "sub" isn't a word of any kind in this context, it's a prefix.
Capitalization goes between words, not inside them.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] StringUtils.subarray v/s subArray
Posted by __matthewHawthorne <ma...@phreaker.net>.
It seems to depend on whether we see the word "array" as a proper noun.
java.lang.String has both substring and subSequence. There seem to be
inconsistencies everywhere.
I vote for subArray, since I would define a classname as being a proper
noun.
Stephen Colebourne wrote:
> I changed this based on subList() in the collections API. substring() is an
> alternative precedent, so I am open to opinions.
>
> Stephen
>
> ----- Original Message -----
> From: "Ash .." <eq...@hotmail.com>
>
>>Thanks for integrating the subarray implementation patch.
>>
>>However, I am curious to know why Stephen chose to name the method
>>"subArray", in place of
>>"subarray".
>>In the English language, the prefix "sub" in this sense is joined to the
>>word with the resultant word being a single "token": subunit, subclass,
>>suburbs, subway... substring, subarray,
>>whereby, as per standard Java conventions, the name ought to be "subarray"
>>rather than "subArray".
>>Even names in Standard API reflect this: substring, etc.
>>
>>thanks,
>>Ashwin
>>
>>_________________________________________________________________
>>Tired of 56k? Get a FREE BT Broadband connection
>>http://www.msn.co.uk/specials/btbroadband
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] StringUtils.subarray v/s subArray
Posted by Stephen Colebourne <sc...@btopenworld.com>.
I changed this based on subList() in the collections API. substring() is an
alternative precedent, so I am open to opinions.
Stephen
----- Original Message -----
From: "Ash .." <eq...@hotmail.com>
> Thanks for integrating the subarray implementation patch.
>
> However, I am curious to know why Stephen chose to name the method
> "subArray", in place of
> "subarray".
> In the English language, the prefix "sub" in this sense is joined to the
> word with the resultant word being a single "token": subunit, subclass,
> suburbs, subway... substring, subarray,
> whereby, as per standard Java conventions, the name ought to be "subarray"
> rather than "subArray".
> Even names in Standard API reflect this: substring, etc.
>
> thanks,
> Ashwin
>
> _________________________________________________________________
> Tired of 56k? Get a FREE BT Broadband connection
> http://www.msn.co.uk/specials/btbroadband
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org