Two things.



1) Re-naming is an inherently bikeshed-ing prone task.

2) Use data to make better arguments.




Are there stack overflow posts, or blog posts, or any kinds of numbers where we 
can point to people actually mis-using this? I agree that the name is 
ambiguous, however i'm pretty sure i've never seen a student mis-use it.




Deprecations aren't taken lightly as even if it is "a simple find and replace" 
it adds a barrier to upgrading that all add up. Not saying we should never 
deprecate, but we should be careful we're deprecating things that have high 
impact/value. Numbers can help. 




Also not saying that these problems don't exist if we can't find evidence of 
them, merely that they might not be as impactful.


---Richard Schneeman


http://www.schneems.com

On Wed, Feb 4, 2015 at 6:06 PM, Pedro Nascimento <[email protected]>
wrote:

> Rails is supposed to be developer-friendly AFAICT, so if the name is indeed
> misleading and makes people assume this feature is meant for something
> else, we should probably rename it specially given there's a major version
> being worked on.
> On Wed, Feb 4, 2015 at 4:08 PM, Nicolas Cavigneaux <[email protected]> wrote:
>>
>> Le 4 févr. 2015 à 12:00, Magne <[email protected]> a écrit :
>>
>> > I ran into a situation with .html_safe when communicating with a fellow
>> programmer, and discovered that the method name isn't as clear as desired.
>> >
>> > .html_safe does not mean "please make this html safe", it's the opposite
>> - it is you the programmer telling rails that "this string is html safe,
>> promise!"
>> >
>> > This can be confused by programmers, and hence be a potential security
>> risk. A programmer should be able to read the name of a method and
>> unambiguously be able to predict what it does, precisely.
>>
>> Every Rails developer, even beginners should be aware of #html_safe and
>> how it works since Rails escapes all strings by default. If the developer
>> wants to use #html_safe then there are two possibility:
>>
>> - he do wants to mark the string as safe so he searched how to do it and
>> found #html_safe. Everything is OK.
>> - he saw #html_safe somewhere, didn’t even try to see if strings are
>> already escaped or not, didn’t even read the API doc for #html_safe. He was
>> just like « Ok I’m going to put this everywhere to secure my code ! »
>>
>> This second developer is dumb… Sorry. It means he didn’t even read any doc
>> or the Rails guide. Don’t let him touch your code until he knows some basis!
>>
>> I think even a beginner should be aware that Rails escapes strings for
>> you. If he isn’t aware of that he needs some training or at least to have
>> some read.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Ruby on Rails: Core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To post to this group, send email to [email protected].
>> Visit this group at http://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Reply via email to