Re: Module name hierarchy...

[BC]

Thanks to Dan for that superlative example and Domi who asked:


... provided your Class::Fault is relatively generic. I.e. can it be
used by an unrelated module ?


The module will indeed be generic.  It will be yet another way to
solve the common problem of error handling and reporting.  So since
there is no requirement for each step in the path to be an existing
module, I will go with

   Class::Fault::Foobar

where 'Foobar' will be some sort of descriptive name that attempts to
succinctly identify the strategy or approach being used for handling
faults.

Many thanks to all who took time to reply.

...BC

Re: Module name hierarchy...

[Dominique Dumont]

On Wednesday, 30 September 2020 07:55:40 CEST BC wrote:
> I can avoid the whole problem by
> just picking a different but similar name:
> 
> Class::Fault
> 
> which is currently not used.  For my purposes that name works well.
> The only thing I don't like is that it feels like I am squatting on
> something fairly generic near the top of the name space.  

Which would fine fine provided your Class::Fault is relatively generic. I.e. 
can 
it be used by an unrelated module ?

> If I were to
> push my one and only module down a level as:
> 
> Class::Fault::Foobar
> 
> would it be a faux pas if there is no Class/Fault.pm or anything else
> at that second level?

If your Fault module is coupled to Foobar, why not create a Foobar::Error (or 
Foobar::Fault) module ?

For the record, I've chosen the latter approach with Config::Model::Exception.

HTH

Re: Module name hierarchy...

[Dan Book]

On Wed, Sep 30, 2020 at 1:56 AM BC  wrote:

> The only thing I don't like is that it feels like I am squatting on
> something fairly generic near the top of the name space.  If I were to
> push my one and only module down a level as:
>
> Class::Fault::Foobar
>
> would it be a faux pas if there is no Class/Fault.pm or anything else
> at that second level?
>

There is no requirement or reason that each step of the module hierarchy
needs to exist as a separate module. (Just imagine if that was needed for
https://metacpan.org/pod/Acme::Working::Out::Dependencies::From::META::files::Will::Be::Wrong::At::Some::Point::Like::This::Module::For::Instance
)

-Dan

Re: Module name hierarchy...

[BC]

Thanks to John, David, and Dan for their thoughts on my module naming
question.  So to avoid potentially tromping on another author's name
space doing something like:

   Class::Error::Foobar

where `Class::Error` already exists, I can avoid the whole problem by
just picking a different but similar name:

   Class::Fault

which is currently not used.  For my purposes that name works well.
The only thing I don't like is that it feels like I am squatting on
something fairly generic near the top of the name space.  If I were to
push my one and only module down a level as:

   Class::Fault::Foobar

would it be a faux pas if there is no Class/Fault.pm or anything else
at that second level?

...BC

Re: Module name hierarchy...

[John M. Gamble]

On Fri, September 25, 2020 4:12 pm, David Cantrell wrote:
> On 25/09/2020 19:59, Dan Book wrote:
>> On Fri, Sep 25, 2020 at 2:20 PM BC > > wrote:
>>
>> Let's say I wanted to submit a module named:
>>
>>       Class::Error::Foobar
>>
>> Would this be considered bad form if my "Foobar" module is not
>> related
>> to the existing Class::Error module in any way?  In other words,
>> Foobar does not depend on, extend, nor reference the Class::Error
>> module other than perhaps a courtesy "See Also" mention.
>>
>> It is not necessarily bad form, but if there is an existing
>> "Class::Error" ecosystem you might consider asking the author first in
>> case they wanted to use that sub-namespace. That does not really seem to
>> be the case here.
>
> I'd say that you should ask no matter what, and should also consider
> using something like Foobar::Error instead. Partly to avoid trampling on
> someone else's namespace, but also because using C::E::Foobar might give
> your users some incorrect expectations if they are already using
> Class::Error elsewhere.
>
> --
> David Cantrell
>
>

I'm of two minds. If the top and second level is large enough then it's
possible that the "ecosystem" has escaped the menagerie and it not really
under the top-and-second namespace author's control. Likewise, if the
author is clearly limiting their module to one purpose, then I don't
believe this is an issue.

But that's making assumptions that I don't know are true about your case.
If neither one is true, then yes, contact the author.

Disclosure of bias on my part: I am the author of Math::Polynomial::Solve,
and the then-author of Math::Polynomial was clearly an example of the
second case.

 --john

Re: Module name hierarchy...

[David Cantrell]

On 25/09/2020 19:59, Dan Book wrote:
On Fri, Sep 25, 2020 at 2:20 PM BC > wrote:


Let's say I wanted to submit a module named:

      Class::Error::Foobar

Would this be considered bad form if my "Foobar" module is not related
to the existing Class::Error module in any way?  In other words,
Foobar does not depend on, extend, nor reference the Class::Error
module other than perhaps a courtesy "See Also" mention.

It is not necessarily bad form, but if there is an existing 
"Class::Error" ecosystem you might consider asking the author first in 
case they wanted to use that sub-namespace. That does not really seem to 
be the case here.


I'd say that you should ask no matter what, and should also consider 
using something like Foobar::Error instead. Partly to avoid trampling on 
someone else's namespace, but also because using C::E::Foobar might give 
your users some incorrect expectations if they are already using 
Class::Error elsewhere.


--
David Cantrell

Re: Module name hierarchy...

[Dan Book]

On Fri, Sep 25, 2020 at 2:20 PM BC  wrote:

> Let's say I wanted to submit a module named:
>
>  Class::Error::Foobar
>
> Would this be considered bad form if my "Foobar" module is not related
> to the existing Class::Error module in any way?  In other words,
> Foobar does not depend on, extend, nor reference the Class::Error
> module other than perhaps a courtesy "See Also" mention.
>

It is not necessarily bad form, but if there is an existing "Class::Error"
ecosystem you might consider asking the author first in case they wanted to
use that sub-namespace. That does not really seem to be the case here.

-Dan