Using a class namespace for subclasses

[Trans]

Wondering the general feeling about using the class namespace for
subclasses. Basically I have a number of specialized Hash classes:
OrderedHash, SyncHash, StaticHash. But I'm thinking it might be more
elegant to name them: Hash::Ordered, Hash::Sync, Hash::Static. Is that
a better way to go or no?

Thanks,
T.

 

[Timothy Hunter]

Wondering the general feeling about using the class namespace for
subclasses. Basically I have a number of specialized Hash classes:
OrderedHash, SyncHash, StaticHash. But I'm thinking it might be more
elegant to name them: Hash::Ordered, Hash::Sync, Hash::Static. Is that
a better way to go or no?

Thanks,
T.

Use a module to contain the classes:

module Hash
class Ordered
...
end
class Sync
...
end
class Static
...
end
end

myhash = Hash::Ordered.new

 

[James Edward Gray II]

Use a module to contain the classes:

module Hash

Na, there's already a Hash constant defined in Ruby, so that wouldn't
make much sense.

For what it's worth, I like the idea of moving them to the Hash
namespace.

James Edward Gray II

 

[Joel VanderWerf]

Use a module to contain the classes:

module Hash
class Ordered
...
end
class Sync
...
end
class Static
...
end
end

myhash = Hash::Ordered.new

irb(main):001:0> module Hash; end
TypeError: Hash is not a module
from (irb):1

but "class Hash" works.

I think the OP was asking whether this approach--using the Hash
namespace--which seems more elegant, might have some drawbacks. It might
set you up for some conflicts with constants other code defines in the
Hash namespace.

 

[Ara.T.Howard]

Wondering the general feeling about using the class namespace for
subclasses. Basically I have a number of specialized Hash classes:
OrderedHash, SyncHash, StaticHash. But I'm thinking it might be more
elegant to name them: Hash::Ordered, Hash::Sync, Hash::Static. Is that
a better way to go or no?

Thanks,
T.

i'd do

module HashTable
class Ordered; end
class Sync; end
class Static; end
end

cheers.

-a
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| My religion is very simple. My religion is kindness.
| --Tenzin Gyatso
===============================================================================

 

[gabriele renzi]

James Edward Gray II ha scritto:

For what it's worth, I like the idea of moving them to the Hash namespace.

+1

 

[Trans]

i'd do

module HashTable
class Ordered; end
class Sync; end
class Static; end
end

cheers.

You would keep it seperate. Why so?

T.

 

[Brian Candler]

irb(main):001:0> module Hash; end
TypeError: Hash is not a module
from (irb):1

but "class Hash" works.

I think the OP was asking whether this approach--using the Hash
namespace--which seems more elegant, might have some drawbacks. It might
set you up for some conflicts with constants other code defines in the
Hash namespace.

True, but I think the only way to be 100% sure of avoiding that is to use a
vendor namespace.

module VanderWerf
module Hash
class Ordered; end
end
end

or VanderWerf::Joel in case there are multiple VanderWerfs developing Ruby
code Actually a domain name or E-mail address would be better.

Usually though, we just accept the risk. There's a risk that a future
version of Ruby (as well as another 3rd party library) might introduce its
own Hash::Ordered; equally, though, it might introduce OrderedHash.

Regards,

Brian.

 

[George Moschovitis]

For what it's worth, I like the idea of moving them to the Hash namespace.

+1

As I said in the Nitro mailing list I like your idea!

-g.

PS: hope to see a new release soon

 

[Ara.T.Howard]

You would keep it seperate. Why so?

T.

i dunno - some namespaces aren't likely to get polluted because there not that
often used. Hash, however, has got to be one of the top candidates, along
with Array, for sticking stuff into. that reminds me, what i did for
arrayfields, which adds a bunch of methods to Array __instances__ is something
like

module ArrayFieldable
def foo
...
...
end
def bar
...
...
end
end

class Array
def fields= fields
self.extend ArrayFieldable
...
...
end
end

so Array got polluted with only one method but certain Array instances get
tons of methods clobbered when ArrayFieldable is included. by sticking your
classes into a separate module one would only need

class Hash
include HashTable
end

or, selectively (i do this alot)

class Hash
Ordered = ::HashTable::Ordered
end

and then one could

ho = Hash::Ordered::new

yet any problems/nameclashes could be solved by just using

ho = HashTable::Ordered::new

so you can have your cake and eat it too. i guess it seems easier to bundle
up names and allow people to import than to inject them into a class and make
people pull them out in the case of problems.

2cts.

cheers.

-a
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| My religion is very simple. My religion is kindness.
| --Tenzin Gyatso
===============================================================================

 

[Trans]

PS: hope to see a new release soon

Getting there. Just a couple more things, then I just have to go
through and clean up the tests. I'd say within the week if all goes
well.

T.