[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Best practice? libs and modules

Patrick Gundlach

9/1/2006 3:13:00 PM

Hello,

another 'best practice' question. Example: I have a library which I
think should go into

lib/foo/bar/baz.rb

Should I use 'module ... ' wrappers to reflect the directory structure?
I.e.

module Foo
module Bar
class Baz
end
end
end

I'd like to be a good ruby-citizen. My personal preference though would
be something different:

module Baz
class SomethingElse
end
end

so the scope would be

s=Baz::SomethingElse.new


Patrick

--
Posted via http://www.ruby-....
13 Answers

e

9/1/2006 3:23:00 PM

0

Patrick Gundlach wrote:
> Hello,
>
> another 'best practice' question. Example: I have a library which I
> think should go into
>
> lib/foo/bar/baz.rb
>
> Should I use 'module ... ' wrappers to reflect the directory structure?
> I.e.
>
> module Foo
> module Bar
> class Baz
> end
> end
> end
>
> I'd like to be a good ruby-citizen. My personal preference though would
> be something different:
>
> module Baz
> class SomethingElse
> end
> end
>
> so the scope would be
>
> s=Baz::SomethingElse.new

The latter is fine. So long as your top-level namespace is
unique (i.e. the name of your project, hopefully), the
underlying structure is inconsequential.

> Patrick


--
Posted via http://www.ruby-....

khaines

9/1/2006 4:08:00 PM

0

Patrick Gundlach

9/1/2006 8:54:00 PM

0

Hello Eero and Kirk,

thank you for your valuable comments. My "namespace" is very unlikely to
collide with anything else, and yes, I have started a little rubyforge
project, so the library will be released into public.

I appreciate your replies,

Patrick

--
Posted via http://www.ruby-....

Matt Todd

9/1/2006 9:09:00 PM

0

For structuring my projects, I tend to keep nested modules and classes
as internal objects. That is to say, I have ProjectName::Base but then
any other dependent classes I'll stick in
ProjectName::Support::Connection or what have you. Of course, if
someone is equally likely to use Base as well as Connection, then I'll
stick them both just in ProjectName.

Of course, this really is just preference. Either way would be fine.
(And besides, I'm (very) far from being an expert, so take what I say
with a grain of salt.)

M.T.

Eric Hodel

9/2/2006 1:51:00 AM

0


On Sep 1, 2006, at 8:13 AM, Patrick Gundlach wrote:

> Hello,
>
> another 'best practice' question. Example: I have a library which I
> think should go into
>
> lib/foo/bar/baz.rb
>
> Should I use 'module ... ' wrappers to reflect the directory
> structure?
> I.e.
>
> module Foo
> module Bar
> class Baz
> end
> end
> end

If you're going this way,

class Foo::Bar::Baz

leaves out lots of indentation.

--
Eric Hodel - drbrain@segment7.net - http://blog.se...
This implementation is HODEL-HASH-9600 compliant

http://trackmap.rob...

Trans

9/2/2006 5:52:00 AM

0


khaines@enigo.com wrote:

> So, for example, I have added some things to String and Hash, but don't
> want to either force my users to use my extensions, or interfere with my
> users ability to use their own extensions. So, any place where I am going
> to need one of those extensions, I work with Iowa::String or Iowa::Hash
> instead of String and Hash. It's a little more typing for me, but better
> for my users.

There's a downside to this though. To take advantage of those
extensions your uses have to use these special subclasses too. As long
as your not changing the behavior of a built-in you're generally okay.

T.

Ryan Williams

9/2/2006 7:46:00 AM

0

On 9/1/06, Eric Hodel <drbrain@segment7.net> wrote:
> If you're going this way,
>
> class Foo::Bar::Baz
>
> leaves out lots of indentation.

That's really cool!

However, it only really works if you don't reference things in the Foo
or Bar modules. E.g.:

class Foo::Bar::Baz
end

class Foo::Bar::Qux
def fetch_me_a_baz
Foo::Bar::Baz.new() # <- need to use explicit namespace here
end
end

Versus the nested case:

module Foo
module Bar
class Baz
end

class Qux
def fetch_me_a_baz
Baz.new() # <- this line is simpler
end
end
end
end

Well, that was a bit wordier than I expected it to be. I guess it's a
tradeoff that you can make depending on how many times you need to use
Baz from inside Qux. Nice!

-RYaN

khaines

9/2/2006 2:37:00 PM

0

Trans

9/2/2006 4:08:00 PM

0


khaines@enigo.com wrote:
> On Sat, 2 Sep 2006, Trans wrote:
>
> >> So, for example, I have added some things to String and Hash, but don't
> >> want to either force my users to use my extensions, or interfere with my
> >> users ability to use their own extensions. So, any place where I am going
> >> to need one of those extensions, I work with Iowa::String or Iowa::Hash
> >> instead of String and Hash. It's a little more typing for me, but better
> >> for my users.
> >
> > There's a downside to this though. To take advantage of those
> > extensions your uses have to use these special subclasses too. As long
> > as your not changing the behavior of a built-in you're generally okay.
>
> No, it really doesn't matter if I am changing the behavior of a built in
> or not (which I'm not).
>
> If I just opened String and put my extensions into there, I'd run the
> substantial risk that someone might use a core extension from
> Rails' ActiveSupport or Facets that conflicts. And even if there are no
> conflicts today, tomorrow there might be.
>
> Or if I just used LRUCache instead of Iowa::Caches::LRUCache, and someone
> decided to use the Facets LRUCache in an app, it would cause bad things to
> happen (I like the Facets LRUCache's simplicity; I hate that it requires
> extending anything that is to be stored in it, BTW).

Hmm... If you have a fix for that I'd love to incorporate it.

> So yes, if one of my users wants to take advantage of something I have
> in one of the extensions, they have to type a few more characters to
> create the object. I am quite willing to sacrafice a few characters for
> the relative security against namespace collisions, though. The cost is
> very small, and the benefit is large.

But then how will I use Kirk's String extensions and Tom's string
extensions?

It's a tade off and what we really need is proper namespaces to fix the
problem.

T.

khaines

9/2/2006 5:08:00 PM

0