On 03/09/2011 22:25, Uri Guttman wrote:
>>>>>> "RD" == Rob Dixon<rob.di...@gmx.com> writes:
>
> RD> On 03/09/2011 21:34, Uri Guttman wrote:
> >> Ron Weidner<xecro...@yahoo.com> wrote:
> >>
> >> first off, arrays have nothing (or little) to do with OOP. you are
> using
> >> arrays inside an object but the code at that point is just plain perl.
>
> RD> That is a strange assertion. So OO software is more to do with
> scalars?
> RD> Or hashes? I will buy that Perl objects are generally blessed
> references
> RD> to hashes, but this is an anonymous array as the value of the base
> hash
> RD> object.
>
> actually in this example a hash ref is the object. the array in question
> is a ref inside the hash. so if you ripped out all the OO code, it would
> still have the same issues as he has now. or put it another way, he has
> both OO and array issues in his code. but he has no array OO issue. :)
Maybe I misunderstood. Were you saying that the subject line of Ron's
post shouldn't have mentioned OOP? That would suppose that he knew the
answer to his question before posting it. Or were you perhaps trying to
simplify the concept by saying that object-orientation is irrelevant?
> >>>
> >>> Can't call method "attrib" on unblessed reference at ./test.pl line
> 40.
> >>>
> >>> $config = new Widget();
>
> RD> That is an "indirect method call" and a nice syntax, especially
> because
> RD> it looks like C and reads like English, except that it is ambiguous.
> RD> Suffice to say that it is bad manners to call the constructor that way
> RD> (and even those who denounce it will have to look up why it is so
> bad).
>
> >> you should call that with a direct method call and declare it with
> >> my. also config is a bad name for a widget object, even in an example.
>
> RD> OK, so Uri says never to call an object $config, so $config2 should
> RD> suffice. It's not a Widget object Uri, it's the thing that has an
> array
> RD> of Widgets.
>
> so @widgets or whatever. but it isn't a config in any way shape or
> form. name should reflect the usage of the data, not be just a
> placeholder or mnemonic.
Again I am lost. It isn't a 'widget object' it is an object that,
probably amongst other things, contains an array of widgets. Perhaps you
are saying that any such object (perhaps a GUI-related one) couldn't
possibly be a configuration in any sense? I find that a long stretch.
> >> my $config = Widget->new();
>
> RD> There is a big difference between
>
> RD> Widget->new();
>
> RD> and
>
> RD> Widget->new;
>
> RD> and more often than not you will want the latter. Much like
>
> not for method calls. both pass no args other than the object itself.
I agree, except that the first parameter here is the class (package)
name rather than an object.
> RD> use MyModule;
>
> RD> is more likely to be right than
>
> RD> use MyModule ();
>
> that is a very different case as perl itself is parsing and handling
> that and will call the import method differently based on it.
Yes. I withdraw this point.
> >>> my $i = 0;
> >>> for ($i=0; $i<3; $i++)
> >>
> >> don't declare $i before the loop. it can be declared in it. also use
> >> perl style loops and not c style when you can:
> >>
> >> foreach my $i ( 0 .. 3 ) {
>
> RD> Yes about the declaration, but Uri means
>
> RD> foreach my $i (0 .. 2) {
>
> off by one error. common enough. it is why c style loops are harder to
> read. my error make a good case for this.
We agree completely here. I was correcting something that I assumed was
an oversight on your part.
> >> you don't show that method. also your comment's method name doesn't
> >> agree with the actual method name. be consistant.
>
> RD> No he doesn't. But it's nothing to do with the problem Uri. Also, it's
> RD> 'consistent'.
>
> no it isn't consistant. the name in the comment wasn't the same name in
> the call. how you call that consistant is the question.
I was being picky and correcting your spelling. Just as you were being
picky and correcting his comments!
> >>> $config->add_widget($w); #this is what I'm testing
> >>
> >> and where is the code for this?
>
> RD> He hasn't shown it. Ron is a beginner.
>
> right. i am asking him to show all the related code as a teaching
> point.
I don't think your comment conveys a polite request to see the rest of
the code, I think it sounds like a telling off directed at someone who
should know better. But as a beginner I am sure he thought he had posted
what was relevant.
> >>> }
> >>
> >>> foreach my $w ( $config->get_widgets() )
> >>> {
> >>> #attrib is tested and working, but this foreach loop is not known to
> be valid code yet.
> >>> print $w->attrib("name"); #<---- This is line 40.
> >>
> >> again, where is the code for this method? usually you can't debug
> method
> >> calls without seeing the method code.
> >>
> >> uri
>
> RD> So Uri skips over the likely cause of the problem: that the
> RD> 'get_widgets' method probably returns an array reference rather than a
> RD> list.
>
> i didn't look into that. you seem to be in a poor mood again. please be
> more careful when you are in such a mood.
Not at all. I was once highly distressed and needed to apologise for a
post I made, and I hope I won't now be forever damned as being in a foul
mood whenever I disagree with you. My wife is an excellent indicator of
whether or not I am in a bad mood, and she would very quickly have said
something if I was overly irritable that night.
Ron shows this code
sub add_widget {
my $self = shift;
my $new_widget = shift;
push ( @{$self->{WIDGETS}}, $new_widget );
}
sub get_widgets {
my $self = shift;
return $self->{WIDGETS};
}
So get_widgets can only ever return a scalar, and presumably it is
meant to be an array reference.
foreach my $w ( $config->get_widgets() ) {
print $w->attrib("name"); # <---- This is line 40.
}
That looks very much like $config->get_widgets needs to be dereferenced
to an array. As it is, the print statement is trying to call
$config->{WIDGETS}->attrib("name");
and because $config->{WIDGETS} is an unblessed reference, the error
message is delivered
Can't call method "attrib" on unblessed reference
None of this reasoning needs sight of more of the code, better comments,
or different variable names, and while those points may be useful as
gentle suggestions you seem to have completely failed to answer Ron's
question.
Rob
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
