Forum: Ruby Organizing code to avoid name space collision

Hello,


I need some hints to organize my code, so I avoid name space collision
of the method patmatch() - which happens when I run the unit test suite.

The layout of my code is here:

http://pastie.org/5483165


Cheers

On Wed, Dec 5, 2012 at 12:17 PM, Martin Hansen <lists@ruby-forum.com> 
wrote:
> I need some hints to organize my code, so I avoid name space collision
> of the method patmatch() - which happens when I run the unit test suite.
>
> The layout of my code is here:
>
> http://pastie.org/5483165

It depends on the lifetime of the association between a Seq instance
and a particular #patmatch algorithm.  Basically these are the options

1. all instances of Seq have the same algo (what you currently have,
implemented via include)
2. an instance of Seq has an algo for its entire lifetime (can be
decided any time, implemented via extend)
3. an instance of Seq can change the algorithm at will (typical case
for delegation aka strategy pattern).

Your tests apparently require at least 2, maybe 3 but your
implementation only delivers 1.  That looks like a design issue.

Kind regards

robert

Thanks Robert,


I don't know if this is a design issue on my part - or how to resolve 
it. The individuel test_backtrack.rb and test_dynamic.rb runs just fine. 
Any script I have that utilizes one of these modules also have no issues 
- because both modules are never included at the same time. It's only 
the test suite that includes both when running rake test - and problems 
occur.

I spend some time studying the Modeles and Namespaces section in the 
Ruby Cookbook. Here the suggestion is that one should chose different 
method names to avoid conflicts. I think that is a crude solution. I 
also explored your extend solution, but while that should work (I didn't 
test) it means that every time I instantiate a Seq object I need to 
extend it. I could accept that for the testing files, but I think it 
would obfuscate the regular code that uses Seq objects. I don't 
understand your 3. suggestion. I am very open to suggestions to improve 
the organization of my code - and to any coding practices that eliminate 
such design issues.



Cheers,


Martin

On Wed, Dec 5, 2012 at 7:28 PM, Martin Hansen <lists@ruby-forum.com> 
wrote:

> I don't know if this is a design issue on my part - or how to resolve
> it. The individuel test_backtrack.rb and test_dynamic.rb runs just fine.
> Any script I have that utilizes one of these modules also have no issues
> - because both modules are never included at the same time. It's only
> the test suite that includes both when running rake test - and problems
> occur.

How is it decided which of the two is included in regular code?

> I spend some time studying the Modeles and Namespaces section in the
> Ruby Cookbook. Here the suggestion is that one should chose different
> method names to avoid conflicts. I think that is a crude solution.

That is obviously a bad solution if you want to use both variants
interchangeably.

> I also explored your extend solution, but while that should work (I didn't
> test) it means that every time I instantiate a Seq object I need to
> extend it. I could accept that for the testing files, but I think it
> would obfuscate the regular code that uses Seq objects.

Not at all.  You can do it in #initialize.  No caller would need to 
change.

> I don't
> understand your 3. suggestion. I am very open to suggestions to improve
> the organization of my code - and to any coding practices that eliminate
> such design issues.

http://c2.com/cgi/wiki?StrategyPattern

Kind regards

robert

> How is it decided which of the two is included in regular code?

I decide if I want backtrack or dynamic matching in the scripts I write 
- and include accordingly.

>> I also explored your extend solution, but while that should work (I didn't
>> test) it means that every time I instantiate a Seq object I need to
>> extend it. I could accept that for the testing files, but I think it
>> would obfuscate the regular code that uses Seq objects.
>
> Not at all.  You can do it in #initialize.  No caller would need to
> change.

OK, extend is the solution. Many thanks Robert.


Cheers,


Martin

On Thu, Dec 6, 2012 at 11:52 AM, Martin Hansen <lists@ruby-forum.com> 
wrote:
>> Not at all.  You can do it in #initialize.  No caller would need to
>> change.
>
> OK, extend is the solution. Many thanks Robert.

You're welcome!

Kind regards

robert

Hello, friend

  Excuse me please, how can I unsubscribe from it?

--
With best regards,
Sergey Zhikharev
"System Telecom"
tel.: +380 44 491-21-08
mob.: +380 67 500-60-40

--
 ,
 ,
" "
.: +380 44 491-21-08
.: +380 67 500-60-40

@Sergey ,

You may mark *ruby-talk@ruby-lang.org* as spam on your email service.

Cheers!


*Mário Luan*
*Linkedin* <http://www.linkedin.com/pub/m%C3%A1rio-luan/31/695/74>
*facebook.com/mariosouzaluan <http://www.facebook.com/mariosouzaluan>*
*@mario_luan <http://twitter.com/mario_luan>*
*TIM (11) 59506744*
*OI (11) 98033-5954*



2012/12/6 Sergey Zhikharev <s.zhikharev@systemtele.com>

see http://www.ruby-lang.org/en/community/mailing-lists/

you send 'unsubscribe' to ruby-talk-ctl@ruby-lang.org

I thought going here would work:
http://www.ruby-lang.org/en/community/mailing-lists/ but even though I
confirmed via email, I am still getting ruby-talk emails.