Yes, I think everyone uses #blank? on enumerables in its current state, and
expect that behavior, because it is well documented.
Rafael Mendonça França
http://twitter.com/rafaelfranca
https://github.com/rafaelfranca
On Tue, Jul 10, 2012 at 3:55 PM, Michael Boutros
wrote:
> Do you think anyone
I use it. It makes total sense to me.
If you have a piece of paper with a list of 10 blank lines, how do you know
there are exactly 10 blank lines instead of 3 or 7 or 13?
On Tue, Jul 10, 2012 at 1:55 PM, Michael Boutros
wrote:
> Do you think anyone currently uses #blank? on enumerables in its c
I don't think that blank? makes sense on anything other than String, no
matter how you define it. My vote would be to deprecate it on Enumerable,
for example, and add something else if desired.
James Coleman
-- Forwarded message --
From: Michael Boutros
Date: Tue, Jul 10, 2012 at
Do you think anyone currently uses #blank? on enumerables in its current
state? It doesn't make sense the way it is right now. Imagine a piece of
paper with a list of 10 blank lines. Wouldn't you call that a blank list?
On Monday, July 9, 2012 10:50:34 AM UTC-4, Xavier Noria wrote:
>
> On Mon, J
On Jul 10, 2012, at 12:29 PM, Prem Sichanugrist wrote:
> Yeah, Jay. Your solution won't work with inheritance.
>
> By deprecating the attr_protected, you can allow most of the attributes
> anyway (but seriously seriously seriously discouraged) by do something like:
>
>attr_accessible colum
Prem,
What's the conflict with inheritance?
Cheers,
Jay
On Tue, Jul 10, 2012 at 12:29 PM, Prem Sichanugrist wrote:
> Yeah, Jay. Your solution won't work with inheritance.
>
> By deprecating the attr_protected, you can allow most of the attributes
> anyway (but seriously seriously seriously disc
Yeah, Jay. Your solution won't work with inheritance.
By deprecating the attr_protected, you can allow most of the attributes anyway
(but seriously seriously seriously discouraged) by do something like:
attr_accessible columns - [:created_at, :updated_at]
Having attr_accessible and attr_prot
On Tue, Jul 10, 2012 at 12:36 PM, Kurt Werle wrote:
> On Monday, July 9, 2012 12:10:07 PM UTC-7, Nicolás Sanguinetti wrote:
>>
>> dup doesn't take arguments because in ruby dup doesn't take arguments. It
>> wouldn't make sense to break the semantics of ruby just for this, IMO.
>
>
> I had not cons
On Monday, July 9, 2012 12:10:07 PM UTC-7, Nicolás Sanguinetti wrote:
>
> dup doesn't take arguments because in ruby dup doesn't take arguments. It
> wouldn't make sense to break the semantics of ruby just for this, IMO.
>
I had not considered that. On the other hand:
* it's not like dup calls
Jay, this solution doesn't play nice with inheritance.
Rafael Mendonça França
http://twitter.com/rafaelfranca
https://github.com/rafaelfranca
On Tue, Jul 10, 2012 at 10:59 AM, Jay Feldblum wrote:
> In this type of case, it makes sense either to declare a whitelist or to
> declare a blacklist.
In this type of case, it makes sense either to declare a whitelist or to
declare a blacklist. But it doesn't make much sense to declare both of them.
Solution #3: ActiveRecord (or ActiveModel) should raise if a class declares
both a whitelist and a blacklist of mass-assignable attributes.
class
I'd like to see attr_protected stick around. There are times I'm working with
models and I don't want to communicate the15 fields that can be written to but
rather the two fields that can't.
Best.
Mike
On Jul 10, 2012, at 1:45 AM, Ryan Bigg wrote:
> For the record: I don't mention attr_prot
Sometimes you have a table with a bunch of regular data and one single FK
to protect. I don't think forcing users to whitelist that model is a good
idea.
I prefer Rails to provide both options (three if you count declaring
nothing) and leave the judgement of what's appropriate in every situation
t
13 matches
Mail list logo
