On Sunday, June 30, 2002, at 11:45 , Daniel Gardner wrote:
> Sunday, June 30, 2002, 5:57:23 PM, drieux wrote:
>
> I don't know if it's just me, but I didn't really understand
> what you're actually trying to achieve...
[..]
> This sounds straightforward:
>
> package FOO::BAR::BOB;
> use base 'FOO::BAR::BAZ';
p0: I knew that there had to be a part of the docs I
had missed about other ways to go about solving the
'multiple class inheritance' types of issues....
>> So while muddling this affair I opted to do the following
>> trick in the FOO::BAR class package:
>
>> # our private defaults - things starting in a Capital
>> # are 'public' elements, things in 'lower case', should
>> # NOT be messed about by anyone but this module...
>> # caveat emptor
>
> But then you start mentioning public and private variables,
> and other things.
>
>> our %def =(
>> Exposed_A => undef,
>> Exposed_B => 666,
>> Exposed_C => 'frodo',
>> private_fd => undef,
>> );
p1: this could be my 'language' problem - since my Idea here
is that I am making an 'object' - that will have both
1.1: 'publically accessible' methods
eg: you read about it in the POD,
hence that part of the API has to hold
1.2: publically accessible variables
eg: things which it is somewhat OK-ish to
access directly without needing to encapsulate
behind get/set methods - { probably a dangerous idea }
hence the flip side of the 'public' stuff are things that I need
to have around to get the job done - which the reasonable person
will not wish to access directly.... sort of the simple rule:
IF it is Public - then I will try to maintain backward
compatability on this for as long as I can
IF it is Private - try not to grab into the object to
play with it - hence If you coded to my defects,
do not be surprised if your code breaks when I fix my bugs...
{ there is the stuff that we 'publically' admit to in the POD,
that helps folks using our module get what needs to be done,
then there is also the 'private' stuff we hide in the README
and/or - forgive the phrase 'the_geek_pod' - files to the GEEKS
who will be thinking about sub_classing "underneath" a given class.... }
[..]
>> #------------------------
>> # So that we have a way to redefine our Values.
>> sub redefine {
>
> What is this "redefine" supposed to do?
p2: My premise had been to have a generic set method,
that would Stuff Stuff into the blessed $self....
I of course wanted to start with hiding 'the default values'
that would be the minimum required to play - so that in the
main the sub_classes would not need to 'reset'/'redefine'
the "default values" unless they had a good reason to do so...
eg:
$gip = DTK::Net::DI704->new();
$ip = $gip->GetOutSideIP();
would use all of the default values through the whole class
hierarchy - to create/use that object class.
But since I do not have an actual DI704 - I have to set up
"psuedo" DI704 dsl/cable router - in this case not a lot
of work - since this is about 'accessing information' through
the web interface on one - hence I would set up the
my %test_off_set = (
.....
);
and play the game:
$gip = DTK::Net::DI704->new(%test_off_set);
$ip = $gip->GetOutSideIP();
verify that it actually 'worked in theory' - ship the
tarball to a friend - who has one - and see if it would work
against a real device...
[..]
>> while( my ($k,$v) = each %hash ) {
>> if ( $k eq 'fd' ) {
>> me->CloseOut() if
>> defined($me->{private_fd});
>> $v = undef unless ( ref($v) eq "PRIVATE:
>> :TYPE");
>> }
>
> And what's a PRIVATE::TYPE?
p3: in this case - a mythological 'object' - that we rested our
class on - hence we need to have one of them in each instance.
In the specific code - that happens to be a FileHandle...
I just didn't want to 'squirrel' the debate by having to
deal with - yes, I know, this is NOT a sane way to do X,Y,Z
since all I am really interested in here is more general understanding
about the 'risks' involved in multiple class inheritance issues
and method overloading cases....
> Perhaps some more explanation about what you're trying to
> do here would be useful.
[..]
p4: verify my understanding that in the base and sub_class class
here I will be able to:
4.1 self reference in ways like that
$me->{'Exposed_A'}
4.2 whine if that value does not exist - don't want to
carp/croak - so have gone for other methods of allowing
the upper level to deal with some of that....
4.3 allow my sub_classes to have their own stack of
"default values" that they can pass through and
get 'initialized' on....
as long as they do not re-interpret the few 'keys'
that I have defined....
hence they too can 'use' the "public"
$me->{'Exposed_A'}
that they 'inherited' from the base class - as
well as 'autoMajically' put in their own stuff
that is findable from their blessed object
$me->{'BOB_A'}
p5: My concern here is to avoid some of the 'object' convolution
that I have seen coded up that requires all sorts of strange
casts to the parent type.... and/or mandating that one implement
all the methods in the 'interface' so that everyone has a fully
safe play space....
ciao
drieux
http://www.wetware.com/drieux/pbl/
--------------
This space left intentionally blank.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
