I agree that this is not worth the effort.
A good way to look at it is I am sure this code is html_safe, so I can
unescape it.
Otherwise non_escapify_html sounds pretty rails-y.
:-P
On Friday, February 6, 2015 at 8:15:38 AM UTC-8, Rafael Mendonça França
wrote:
In our opinion this is
Renaming this method is not an option.
The main reason is: it should not be used by end users. It is an
implementation detail of the framework and although it is exposed to the
users we don't recommend to use it directly.
So when Andrew said we should rename it to something even longer so that
I didn't realise I wasn't supposed to be using html_safe. Perhaps the
documentation should be updated to make this clearer?
On 6 February 2015 at 16:50, Rafael Mendonça França rafaelmfra...@gmail.com
wrote:
Renaming this method is not an option.
The main reason is: it should not be used by
Is Rails' API coded for the neophyte or the experienced dev?
The eternal question.
On Feb 5, 2015, at 7:04 PM, George Millo georgejulianmi...@gmail.com wrote:
In years of using Rails it has never occurred to me that the name html_safe
can be ambiguous until just now when I read this
Le 6 févr. 2015 à 16:21, Jason Fleetwood-Boldt a écrit :
Is Rails' API coded for the neophyte or the experienced dev?
The eternal question.
For people who know how to read basic, essential doc and well documented stuff?
--
Nicolas Cavigneaux
www.bounga.org
www.cavigneaux.net
--
IMHO, the target audience is largely an irrelevant concern. The more important
concept is making users fall into the pit of success. In that light, the
proposed renaming makes sense.
Don't forget, the clearer the intention of the method the better it is for both
novice and experienced
Rafael,
I do agree with you; however, the same argument could be made for renaming it
as well. If it is a private implementation concern and nobody should be using
it, then there should be no problems with a rename to make sure that the name
is scary enough to stop people from using it and/or
Yeah. This is one of the example of things that were supposed to be
implementation detail and became a widely used method, just like
`arel_table`. It is not that you can't use it at all, but that you should
be very careful when using it. Like I said almost 90% of its usages can be
avoided using
In our opinion this is will cause an unnecessary amount of work to people
upgrading their applications. We want to avoid adding breaking
changes/deprecation if we can.
On Fri Feb 06 2015 at 2:10:33 PM Ufuk Kayserilioglu u...@paralaus.com
wrote:
Rafael,
I do agree with you; however, the same
Renaming it to: .prevent_html_escaping would make it unambiguous, and
directly refer to what is actually being done (so that the programmer
doesn't have to infer what safe means, precisely).
Agreed.
Well, on second thought, I'm not so sure if I find the effort warranted.
But if the method
In years of using Rails it has never occurred to me that the name
html_safe can be ambiguous until just now when I read this thread.
When is a developer going to stumble across this method without knowing
what it means and insert it blindly into their code? If it really *is
*ambiguous,
people
Bikeshedding! Count me in.
How 'bout #is_safe_html.
On 5/02/2015, at 18:59 , Rainer Frey frey.rai...@gmail.com wrote:
Renaming it to: .prevent_html_escaping would make it unambiguous, and
directly refer to what is actually being done (so that the programmer doesn't
have to infer
Hi,
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
Renaming it to: .prevent_html_escaping would make it unambiguous, and
directly refer to what is actually being done (so that the programmer doesn't
have to infer what safe means, precisely).
Yes, we should rename it to something even longer so that people don't use it
:)
Andrew White
--
Also, this is a hugely impactful breaking change to the API. Could it have
a better name? Sure. But at this point it's probably not a good idea to
change it.
On Wed, Feb 4, 2015 at 12:16 PM, Andrew White an...@pixeltrix.co.uk wrote:
Renaming it to: .prevent_html_escaping would make it
Also, this is a hugely impactful breaking change to the API. Could it
have a better name? Sure. But at this point it's probably not a good idea
to change it.
I'm not weighing in on whether to rename it, but on this particular
argument against the rename: I don't think this is a valid reason
Le 4 févr. 2015 à 12:00, Magne magn...@gmail.com 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
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
This is a great example of bikeshedding. I am not sure that was the
intention however.
The method name, for me, means this string is safe to display as-is in
HTML.
Teaching people that this method does this is a simple matter of educating
those people. Changing the method name to suit those who
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
On Wed, Feb 4, 2015 at 12:00 PM, Magne magn...@gmail.com wrote:
Hi,
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
21 matches
Mail list logo
