in reply to Re: Idea on a Base class API
in thread Idea on a Base class API

I do apologize for not explaining myself more clearly. I've focused on data typing, primarily because those are the types of objects I've been working with recently. However, the goal is this:
I have Foo and Bar and Bar inherits from Foo. Since Foo inherits from BaseClass, then all the standard C++/Java OO stuff happens. For instance, if I have the following:
package Foo; use BaseClass; @ISA=qw(BaseClass); Foo->define_attributes( attrib1 => 'NUM', ); package Bar; use Foo; @ISA=qw(Foo); Bar->define_attributes( attrib2 => 'NUM', );

Bar would now have two attributes - attrib2 and attrib1. This would be a full implementation of the is-a style hierarchy, something lacking in the native Perl language.

I'm not looking to create a struct ... I know that's out there and probably done much better than I ever could. However, what I am looking to create is something that would give a solid OO foundation to someone who wants to use it, but doesn't want to re-invent the wheel.

I don't know ... something that maybe does private, friends, shared, public, etc. I'm not quite sure on how far to take this, or even if this would be well-received by the Perl community. This would be my first modules, so I wanted to start a discussion on PM first, to see what people thought of both the idea in general and my idea in specific.

Replies are listed 'Best First'.
Re: Re: Re: Idea on a Base class API
by bikeNomad (Priest) on Jun 13, 2001 at 03:14 UTC
    I see... Don't worry about how it'd be received. The Perl community is very diverse. Chances are very good that if it's useful for you in the kinds of programming you're doing, it'll be useful to someone else too. If you're looking for encouragement, here's some: go for it!. Either what you build will be better than what's out there, or it'll feel better to you to use, or at least you'll learn a lot doing it. And, with CPAN and Perlmonks, you'll have the advantage of sharing it with others who might find it useful too.

    As far as the technical end, it might be useful to provide a switch of some sort to turn on/off access checking of various kinds. That is, when you're testing or developing, you can check for adherence to the contract (private/public/protected, compatible types, etc.), and be able to switch off the checking later. If you do it right, you can make it run faster without checking.

    To check for violation of visibility, you could use caller() to see where you're being called from.

    Good luck!