Issue #16348 has been updated by naruse (Yui NARUSE).=0D
=0D
=0D
duerst (Martin D=FCrst) wrote:=0D
> I personally think that we should be restrictive in adding new methods to=
 `Symbol`. Otherwise, this very quickly becomes a slippery slope, and the d=
istinction between `Symbol` and `String` becomes less and less clear.=0D
>=20=0D
> I was personally surprised when I implemented feature #10085 that `Symbol=
` had `#upcase` and friends, I wouldn't have guessed that.=0D
=0D
As far as I remember, once Matz tried and gave up to unify String and Symbo=
l, he said Symbol should have similar set of methods while people needed.=0D
After a decade some but small number of methods are added even if including=
 this.=0D
I think there's no worry.=0D
=0D
----------------------------------------=0D
Feature #16348: Proposal: Symbol#start_with?, Symbol#end_with?, and Symbol#=
include?=0D
https://bugs.ruby-lang.org/issues/16348#change-82866=0D
=0D
* Author: kamipo (Ryuta Kamizono)=0D
* Status: Closed=0D
* Priority: Normal=0D
* Assignee:=20=0D
* Target version:=20=0D
----------------------------------------=0D
When replacing #match? to #start_with?, #end_with?, and #include? for some =
reason (address to https://bugs.ruby-lang.org/issues/13083 etc), we frequen=
tly hit missing Symbol#start_with?, Symbol#end_with?, and Symbol#include? i=
n spite of Symbol#match? exists.=0D
=0D
https://github.com/rails/rails/commit/63256bc5d7dd77b2cce82df46c53249dab2dc=
2a8=0D
https://github.com/rails/rails/commit/a8e812964d711fa03843e76ae50f5ff81cdc9=
e00=0D
=0D
Is this inconsistency intentional?=0D
If not so, Symbol#start_with?, Symbol#end_with?, and Symbol#include? preven=
ts such like an issue.=0D
=0D
=0D
=0D
--=20=0D
https://bugs.ruby-lang.org/=0D