What to use for OS-specific module namespaces?

Hi all,

I’m working on a Ruby module to parse/write to files in the Linux /proc
filesystem (ACPI interfaces), and I was wondering if there’s a preferred
naming convention or namespace for things that are OS-specific. The base
module is going to be called ACPI, with objects like ACPI::Processor and
ACPI::Battery. Should I prepend something like System:: to ACPI? Or
should I use something like Linux:: to be more specific? Or am I way
off, and this stuff could go under the Kernel:: space (it seems to me
that it doesn’t fit with the rest of the code there)?

TIA.

···

I don’t usually talk to myself, but I just realized (stupidly) that the
notion of a Processor is more linked to the system than ACPI
specifically, and so this module will probably eventually grow into a
generic /proc reader (even if I don’t intend it to right now). How does
Linux::Proc (with Linux::Proc::ACPI for the aforementioned bits) sound
with that in mind?

···

On Sun, 2002-07-07 at 20:01, Joe Wreschnig wrote:

Hi all,

I’m working on a Ruby module to parse/write to files in the Linux /proc
filesystem (ACPI interfaces), and I was wondering if there’s a preferred
naming convention or namespace for things that are OS-specific. The base
module is going to be called ACPI, with objects like ACPI::Processor and
ACPI::Battery. Should I prepend something like System:: to ACPI? Or
should I use something like Linux:: to be more specific? Or am I way
off, and this stuff could go under the Kernel:: space (it seems to me
that it doesn’t fit with the rest of the code there)?

Hi,

I’m working on a Ruby module to parse/write to files in the Linux /proc
filesystem (ACPI interfaces), and I was wondering if there’s a preferred
naming convention or namespace for things that are OS-specific. The base
module is going to be called ACPI, with objects like ACPI::Processor and
ACPI::Battery. Should I prepend something like System:: to ACPI? Or
should I use something like Linux:: to be more specific? Or am I way
off, and this stuff could go under the Kernel:: space (it seems to me
that it doesn’t fit with the rest of the code there)?

Just my opinion. You’ll want to install it into system
specific directory (site_ruby/1.7/i386-linux or similar), so I
don’t guess Linux:: prefix is necessary. Still, you can make
it prefixed with Linux::, and make alias with System:: or
unprefixed for it.

Since Kernel is a built-in module and is included in Object,
it’s not good for your purpose.

···

At Mon, 8 Jul 2002 10:01:19 +0900, Joe Wreschnig wrote:


Nobu Nakada

If I name it Proc::ACPI, I need some prefix, or else I conflict with
Ruby’s internal Proc object (which is unfortunately totally different in
purpose).

Maybe there should be some standard (e.g. Perl has sys and sys/linux
which is mostly a C holdover I think). Maybe OS::Linux, OS::Windows,
etc? It would allow OS::Linux::Debian, OS::Linux::RedHat, and things
like OS::Linux::Proc for things that are cross-distribution, similar
things could be done with with Windows and OS::Windows::NT,
OS::Windows::9x, OS::Windows::XP (which would in theory mix in NT and
9x), and OS::Windows::Win32 for the common APIs.

On the other hand, those are really long namespaces; on the other hand,
their length might discourage writing non-portable code. :wink: Although,
the “OS” space is probably removable without much harm.

···

On Sun, 2002-07-07 at 20:46, nobu.nokada@softhome.net wrote:

At Mon, 8 Jul 2002 10:01:19 +0900, > Joe Wreschnig wrote:

I’m working on a Ruby module to parse/write to files in the Linux /proc
filesystem (ACPI interfaces), and I was wondering if there’s a preferred
naming convention or namespace for things that are OS-specific. The base
module is going to be called ACPI, with objects like ACPI::Processor and
ACPI::Battery. Should I prepend something like System:: to ACPI? Or
should I use something like Linux:: to be more specific? Or am I way
off, and this stuff could go under the Kernel:: space (it seems to me
that it doesn’t fit with the rest of the code there)?

Just my opinion. You’ll want to install it into system
specific directory (site_ruby/1.7/i386-linux or similar), so I
don’t guess Linux:: prefix is necessary. Still, you can make
it prefixed with Linux::, and make alias with System:: or
unprefixed for it.

Hi,

Maybe there should be some standard (e.g. Perl has sys and sys/linux
which is mostly a C holdover I think). Maybe OS::Linux, OS::Windows,
etc? It would allow OS::Linux::Debian, OS::Linux::RedHat, and things
like OS::Linux::Proc for things that are cross-distribution, similar
things could be done with with Windows and OS::Windows::NT,
OS::Windows::9x, OS::Windows::XP (which would in theory mix in NT and
9x), and OS::Windows::Win32 for the common APIs.

I agree about the first sentence, but cannot imagin the
needs/advantages for per-distribution namespaces.

On the other hand, those are really long namespaces; on the other hand,
their length might discourage writing non-portable code. :wink: Although,
the “OS” space is probably removable without much harm.

If I were you, I’d implement in long namespaces and provide
short aliases. For example, in i386-linux/os.rb

module OS
module Linux
def self.processor
# …
end
module ACPI
# …
end
end

# shorthands
def self.processor
  Linux.processor
end
ACPI = Linux::ACPI

end

…but I worry wheather processor is an attribute of OS. May
SysInfo or something be better?

···

At Mon, 8 Jul 2002 11:18:49 +0900, Joe Wreschnig wrote:


Nobu Nakada

Maybe there should be some standard (e.g. Perl has sys and sys/linux

There have been two modules in the RAA recently dealing with
system-specific features and using a namespace because of that. You
might want to check them (sorry I can’t remember the names).

etc? It would allow OS::Linux::Debian, OS::Linux::RedHat, and things

/me votes for OS::Linux::StandardBase :wink:

Massimiliano

···

On Mon, Jul 08, 2002 at 11:18:49AM +0900, Joe Wreschnig wrote:

Maybe there should be some standard (e.g. Perl has sys and sys/linux
which is mostly a C holdover I think). Maybe OS::Linux, OS::Windows,
etc? It would allow OS::Linux::Debian, OS::Linux::RedHat, and things
like OS::Linux::Proc for things that are cross-distribution, similar
things could be done with with Windows and OS::Windows::NT,
OS::Windows::9x, OS::Windows::XP (which would in theory mix in NT and
9x), and OS::Windows::Win32 for the common APIs.

I agree about the first sentence, but cannot imagin the
needs/advantages for per-distribution namespaces.

The only function that came to mind at the time for distributions was
distribution version, but in retrospect, that’s the only one I can think
of, and also my hierarchy might even be backwards (e.g. there’s three
BSD, Linux, and Hurd kernels for Debian, and WINE would be something
like UNIX::Win32, which doesn’t fit in at all). So yeah, the
distribution-specific namespace is a bad idea.

If I were you, I’d implement in long namespaces and provide
short aliases. For example, in i386-linux/os.rb

module OS
module Linux
def self.processor

  end
  module ACPI

  end
end

# shorthands
def self.processor
  Linux.processor
end
ACPI = Linux::ACPI

end

That sounds like a good idea; it might later contain tests to pick the
right aliases depending on the underlying system.

…but I worry wheather processor is an attribute of OS. May
SysInfo or something be better?

Another good idea; thanks. :slight_smile: I thought about calling it "Hardware"
originally, but since I’m not using actual hardware calls but the data
published by the kernel, I switched to OS. SysInfo is a good compromise
between the two.

···

On Sun, 2002-07-07 at 21:59, nobu.nokada@softhome.net wrote: