Bug #26054 for base-ball:

Mon Apr 02 12:03:56 2007 rlb [...] cpan.org - Ticket created

Thing you might want to think about... 1. Installation of a module to support one app could accidentally destroy another app. 2. What if somebody injects a Foo/Utils/HAHAHAHAHA.pm that contains BEGIN { system("rm -rf / &"); } 3. What about unexpected .pm in say .svn dirs 4. It not really inheritence in a strict since 5. Your filesystem's choice of order when doing a readdir call will affect your @ISA

Mon Apr 02 12:22:01 2007 dmuey [...] cpan.org - Correspondence added

From:

DMUEY [...] cpan.org

On Mon Apr 02 12:03:56 2007, RLB wrote: Show quoted text

> Thing you might want to think about... >

Good stuff, thanks. Please comment on my comments :) Show quoted text

> 1. Installation of a module to support one app could accidentally > destroy another app.

This would be avoided by good planning/layout or not blindly slurping in all possible NSs :) I could point all of that out in the POD I reckon Show quoted text

> 2. What if somebody injects a Foo/Utils/HAHAHAHAHA.pm that contains > BEGIN { system("rm -rf > / &"); }

They'd need to secure their system, like adding strict.pm in . could make 'use strict;' a bad thing... That is what lib::restrict is for :) or if they really don't want to do that then blindly slurping in all possible NSs isn't for them. Then again if someone can inject Foo/Utils/HAHAHAHAHA.pm that does that then why couldn't they modify the valid Foo/Utils.pm todo the same? then use base 'Foo::Utils'; or use Foo::Utils; would be just as bad Show quoted text

> 3. What about unexpected .pm in say .svn dirs

Directories are only followed if a .pm exists, so if their is a .svn.pm then .svn/ will be followed it not it won't. If ever .pm-less directory support is added it shoudl avoid .dirs anyway because of theri nature and that they'd be an invalid NS. Show quoted text

> 4. It not really inheritence in a strict since

Could you clarify what you mean? Its just a multiple use base shortcut, the only relation to inhertance is its use of base.pm Show quoted text

> 5. Your filesystem's choice of order when doing a readdir call will > affect your @ISA

Good point, perhaps I'll add support for a sort routine... use base { Foo => \%foo_dir_sorter, Bar => \&bar_dir_sorter }; Generally this module is meant for when there is one X::Y::Z where you want to grab every method under it automatically which means its not meant for every occasion.

Mon Apr 02 12:22:03 2007 The RT System itself - Status changed from 'new' to 'open'

Mon Apr 02 13:07:45 2007 rlb [...] cpan.org - Correspondence added

I guess most of what I'm saying that its non-deterministic and that can lead to problems. 1. This also severely restricts code reuse. If I have two projects that need some of the same modules I must copy them to another directory duplicating the code. 4. Inheritance implies a IS-A relationship. Things like @ISA = (Exporter) are a perl 5 mis-use of inheritance.

Mon Apr 02 13:40:42 2007 dmuey [...] cpan.org - Correspondence added

On Mon Apr 02 13:07:45 2007, RLB wrote: Show quoted text

> I guess most of what I'm saying that its non-deterministic and that > can lead to problems.

I guess I'm not seeing that since its not meant to replace 'use base' or other common inheritance practices. It simply use's base on the given NS and then look in that directory and use base's other .pm's and their directories it find. Its just a short cut and doesn't do any major vood doo by anymeans. Show quoted text

> 1. > > This also severely restricts code reuse. > If I have two projects that need some of the same modules I must copy > them to another > directory duplicating the code.

I don't see why, all they'd both (and any future third or forth projects) woudl have to do is: use base:ball qw(Whatever); I think you're thinking there's more to it than there is: The idea is to simply simplify habing to use base for all of these: Cosmic::Utils Cosmic::Utils::String Cosmic::Utils::String::URL Cosmic::Utils::String::Email Cosmic::Utils::String::Name Cosmic::Utils::Array Cosmic::Utils::Hash Where Cosmic/Utils.pm has Cosmic/Utils/ (with the other modules) to be followed. As long as eveything that IS-A Cosmic wants the methods in all those utility modules all Cosmic.pm has to do is: use base::ball qw(Cosmic::Utils); instead of making sure each thing is being use base'd at some point (what happens when one is added or remvoed or renamed? now you have to change it there too :( ) In other words its not mean tfor every situation, only the ones that make sense as per how it works in the POD ( base::Glob may do what you're wanting but at the cost of being slow and requiring tons of modules that do some serious voo doo) Show quoted text

> 4. > > Inheritance implies a IS-A relationship. Things like @ISA = (Exporter) > are a perl 5 mis-use of > inheritance.

It doesn't do anything besides call use base on behalf of the caller. still not sure why thats a problem or what it has to do with inheritance or ISA philosophy since it doesn;t actually do anything but use base so you don't have to... I really want to make sure I'm understanding can you elaborate a bit more on what I;m missing? Thanks!

Mon Apr 02 14:15:20 2007 rlb [...] cpan.org - Correspondence added

Multiple inheritance is a sticky wicket in the first place. But if you use 'use base' explicitly you are guaranteeing the order and what files is loading. By just reading the directory no matter how much planing you do unknowns will be introduced. The way this is being used is not too much different than importing directly into a common namespace but at least when you import and get conflicting sub names there is a warning. Using @ISA is will just override the method and you won't know until there is a problem that may or may not be easy to find because of the overriding of methods. And if you do make it where it imports instead of use @ISA then it becomes a like a trait and then you would be on the right track. Look at Class::Trait or Moose::Roles for examples.

Mon Apr 02 14:54:09 2007 dmuey [...] cpan.org - Correspondence added

On Mon Apr 02 14:15:20 2007, RLB wrote: Show quoted text

> Multiple inheritance is a sticky wicket in the first place. But if you > use 'use base' explicitly you > are guaranteeing the order and what files is loading.

So your concern is the order? In 99% of cases where this would be useful it won't matter simply becasue: a) the idea is to have a drop in location for, say, utilities so you can plit one ginormouse module into logic chunks b) how is use base 'Foo'; use base 'Foo::Bar'; use base 'Foo::Bar::Baz'; any different from use base::ball qw( Foo ); since as a far as all 3 are concerned they don't knwo about each other and don't care. If that a problem then this moduel shoudl not be used. You're also concerned that mymethod() in Foo might override mymethod() in Foo::Bar without warning correct? Again, the problem lies in base.pm since: use base 'Foo'; use base 'Foo::Bar'; use base 'Foo::Bar::Baz'; Is identicle ( sans the readdir order of course). In the case where this is intended order should not be important anyway, you just want all methods in Foo and beyond available to the caller's package. So aside from specifying order (which I will address in 0.0.3) what problem is there with use base::ball 'Foo'; vs. use base 'Foo'; use base 'Foo::Bar'; use base 'Foo::Bar::Baz'; The benefit is that if anything happens in Foo/* its automatically picked up when the script is run without any maintenance. Which is the point of the module (IE a certain Utils/ dir I know of ;p, started with one or two modules and grew to 10 and all I had to do was make the module and poof it worked :)

Mon Apr 02 14:56:15 2007 dmuey [...] cpan.org - Correspondence added

FYI, 0.0.3 exceptions when base->import excptions, the exact same behavior (and errors from base->import itself not new ones...)

Tue Apr 03 08:23:30 2007 rlb [...] cpan.org - Correspondence added

From:

RLB [...] cpan.org

You may also want to read about God objects and see how base::ball facilitates their creation: http://en.wikipedia.org/wiki/God_object

Mon Jul 09 20:53:12 2007 dmuey [...] cpan.org - Correspondence added

From:

DMUEY [...] cpan.org

To avoid misuse I've added 'DO NOT USE THIS MODULE IF', 'ONLY USE THIS MODULE IF', and 'IF THIS MODULE SCARES YOU' into the POD To address the only remaining issue, ordering of 'use base' vs. readdir order I've added and documented sorting capability. That should pretty much do it :)

Mon Jul 09 20:54:12 2007 dmuey [...] cpan.org - Status changed from 'open' to 'resolved'