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.
Trans wrote:
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
i'd do
module HashTable
class Ordered; end
class Sync; end
class Static; end
end
cheers.
-a
On Mon, 25 Jul 2005, Trans wrote:
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.
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
===============================================================================
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
On Jul 24, 2005, at 3:01 PM, Timothy Hunter wrote:
Trans wrote:
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
Timothy Hunter wrote:
Trans wrote:
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
endmyhash = 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 wrote:
i'd do
module HashTable
class Ordered; end
class Sync; end
class Static; end
endcheers.
You would keep it seperate. Why so?
T.
James Edward Gray II ha scritto:
For what it's worth, I like the idea of moving them to the Hash namespace.
+1
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.
On Mon, Jul 25, 2005 at 05:05:55AM +0900, Joel VanderWerf wrote:
> Use a module to contain the classes:
>
> module Hash
> class Ordered
> ...
> end
> class Sync
> ...
> end
> class Static
> ...
> end
> end
>
> myhash = Hash::Ordered.newirb(main):001:0> module Hash; end
TypeError: Hash is not a module
from (irb):1but "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.
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
On Mon, 25 Jul 2005, Trans wrote:
Ara.T.Howard wrote:
i'd do
module HashTable
class Ordered; end
class Sync; end
class Static; end
endcheers.
You would keep it seperate. Why so?
T.
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
===============================================================================
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
--
http://www.nitrohq.com: Nitro Web Engine / Og ORM
George Moschovitis wrote:
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.