On 5 Nov 2008, at 14:28, Fernando Perez wrote:
Hmmm, could you make a helper module and mix that into all three
controllers? Then there'd be just one place to change it.
Can you be more descriptive?
Well I was just thinking out loud really. Something like
module SubscriptionStuff
def s
> You're allowed to disagree :)
>
> Does what we're saying make sense to you?
>
Yes, my model classes were starting to get hard to read with method
calling other methods calling other methods.
Yes, we can change ;-)
--
Posted via http://www.ruby-forum.com/.
_
Thanks David
Just to confirm "up front" was not in any way meant to imply that the design
is fixed or should not be refactored, or even will not need refactoring.
Clarifying my point,
2) Use your tests/specs/stories/features combined with your experience
to ensure you design an initial api that
I feel the same as Andrew, generalizing all calls to the model methods
is bad, as you're making the simple (and common) complicated just to
have the uncommon as possible.
If you're making a big change as changing a method name and adding a
new parameter, you're doing something new, it isn't the sa
On Wed, Nov 5, 2008 at 9:42 AM, Fernando Perez <[EMAIL PROTECTED]> wrote:
> Okay, I wanted to get some external point of views on an idea. Thanks
> for your input.
You're allowed to disagree :)
Does what we're saying make sense to you?
___
rspec-users m
Okay, I wanted to get some external point of views on an idea. Thanks
for your input.
--
Posted via http://www.ruby-forum.com/.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
On Wed, Nov 5, 2008 at 9:12 AM, Andrew Premdas <[EMAIL PROTECTED]> wrote:
> What you are suggesting here changing your api to make it easier to refactor
> your api. Your trying to do this by
>
> 1) Generalising the descriptivness of the api
> 2) Reducing the number of calls to your api
>
> Both of
Fernando Perez wrote:
I don't think this is a problem.
Pat
Don't you find it painful to go through each controller and/or each
controller spec to correct the name of the method that has just changed?
So you don't mind having to change in many different places
should_receive(:find_if_p
What you are suggesting here changing your api to make it easier to refactor
your api. Your trying to do this by
1) Generalising the descriptivness of the api
2) Reducing the number of calls to your api
Both of these are not particularly good ideas
1) Generalising your api, reduces it descriptiv
On Wed, Nov 5, 2008 at 8:53 AM, Fernando Perez <[EMAIL PROTECTED]> wrote:
>> I don't think this is a problem.
>>
>> Pat
>
> Don't you find it painful to go through each controller and/or each
> controller spec to correct the name of the method that has just changed?
>
> So you don't mind having to
On Wed, Nov 5, 2008 at 8:42 AM, Pat Maddox <[EMAIL PROTECTED]> wrote:
> Fernando Perez <[EMAIL PROTECTED]> writes:
>
>>> Hmmm, could you make a helper module and mix that into all three
>>> controllers? Then there'd be just one place to change it.
>>>
>> Can you be more descriptive?
>>
>> Let's sa
> I don't think this is a problem.
>
> Pat
Don't you find it painful to go through each controller and/or each
controller spec to correct the name of the method that has just changed?
So you don't mind having to change in many different places
should_receive(:find_if_purchased) to
should_rece
Fernando Perez <[EMAIL PROTECTED]> writes:
>> Hmmm, could you make a helper module and mix that into all three
>> controllers? Then there'd be just one place to change it.
>>
> Can you be more descriptive?
>
> Let's say I have:
>
> def show
> Subscription.find_if_purchased
> ...
> end
>
> de
> Hmmm, could you make a helper module and mix that into all three
> controllers? Then there'd be just one place to change it.
>
Can you be more descriptive?
Let's say I have:
def show
Subscription.find_if_purchased
...
end
def update
Subscription.find_if_purchased
...
end
Now if I c
On 5 Nov 2008, at 13:17, Fernando Perez wrote:
Let's say I have a class method: Product.find_if_purchased(product_id,
user_id)
Let's say it is called in 3 different controllers.
Hmmm, could you make a helper module and mix that into all three
controllers? Then there'd be just one place to
On Wed, Nov 5, 2008 at 7:17 AM, Fernando Perez <[EMAIL PROTECTED]> wrote:
> The biggest problems I have when developing (beside stupid typos) are:
> 1) The name of a method which I often change to a supposedly more
> descriptive name, which I will eventually change to an even more
> supposedly des
The biggest problems I have when developing (beside stupid typos) are:
1) The name of a method which I often change to a supposedly more
descriptive name, which I will eventually change to an even more
supposedly descriptive name
2) The arguments a method takes
Let's say I have a class method: Pr
17 matches
Mail list logo
