Perl 6 and OOP

[J. Romano]

Greetings!

After doing some work with Object-Oriented Perl (and helping a
friend learn it, as well), we both agree that the Data:umper module
is a valuable tool for debugging OO Perl programs, as it lets us
easily see the structure and contents of complex objects (which is
something I wish more OO languages had readily available).

Now, OO Perl has had its critics, most of which are quick to say
that OO Perl is messy and doesn't enforce private data very well.
However, some do admit that this makes OO Perl quite flexible -- for
instance, a Perl object can be easily examined with the Data:umper
module as a result of its laid-back policy on information hiding.

Now to my question: Knowing that Perl 6 will have better OO
handling, does that mean that Data:umper will lose its usefulness on
Perl 6 objects? Or will it still be able to let a programmer peer
into them and let him/her tinker with their data using the debugger?

I'm hoping for the latter case, even though that case is sure not
to eliminate all of Perl's OO criticisms that gripe about the lack of
information hiding.

-- Jean-Luc

 

[Uri Guttman]

JR> Now to my question: Knowing that Perl 6 will have better OO
JR> handling, does that mean that Data:umper will lose its usefulness on
JR> Perl 6 objects? Or will it still be able to let a programmer peer
JR> into them and let him/her tinker with their data using the debugger?


you seem to be conflating data::dumper and OO. dumper is not an OO tool
but a debugging and data tool. i have (as have many others) used it in
many non-oo programs. it is just a way to dump perl data structures (oo
or not) in a way that can be evaled and also read by hyoomans.

JR> I'm hoping for the latter case, even though that case is sure not
JR> to eliminate all of Perl's OO criticisms that gripe about the lack of
JR> information hiding.

i am not sure what you are talking about. dumper as it is won't do that
in perl6. but there are ways to introspect anything in perl6 (normal
code won't be able to accidentally do that) so dumper can be modified to
do that. i am sure the p6/parrot teams will make sure of that since
dumper is such a useful tool regardless of the OO nature of the data.

uri

 

[Gunnar Hjalmarsson]

you seem to be conflating data::dumper and OO. dumper is not an OO tool

^^^^^^^^^^^^

Time soon to ask somebody to fix that broken shift key? After all,
module names are case sensitive. ;-)

 

[Michele Dondi]

Now to my question: Knowing that Perl 6 will have better OO
handling, does that mean that Data:umper will lose its usefulness on
Perl 6 objects? Or will it still be able to let a programmer peer
into them and let him/her tinker with their data using the debugger?

There will be a predefined method for this. Only, the definitive name
has not been chosen yet. Proposals include, not surprisingly C<.code>,
C<.dump>, etc. Larry has been thinking about C<.perl>, envisioning a
possible future for, say, C<.python>, C<.ruby>, etc.


Michele

 

[J. Romano]

There will be a predefined method for this. Only, the definitive name
has not been chosen yet. Proposals include, not surprisingly C<.code>,
C<.dump>, etc. Larry has been thinking about C<.perl>, envisioning a
possible future for, say, C<.python>, C<.ruby>, etc.

Interesting.

But I'm confused as to what the .perl() method would do. Are you
saying that "$a.perl()" would do the same thing that "Dumper $a" does
now? And if that's so, what would "$a.python()" and "$a.ruby()"
generate? (Code that can be eval()'ed in those respective languages,
maybe? That would be very interesting, I would think. Molto
interessante...)

-- Jean-Luc

 

[Michele Dondi]

But I'm confused as to what the .perl() method would do. Are you
saying that "$a.perl()" would do the same thing that "Dumper $a" does

Yes, it will yield a stringified perl representation of its object.

now? And if that's so, what would "$a.python()" and "$a.ruby()"
generate? (Code that can be eval()'ed in those respective languages,
maybe? That would be very interesting, I would think. Molto
interessante...)

Yes, *if* python and ruby *do* support such a thing, I'd say.
(Disclaimer: as you may have already understood, I don't know anything
about these two languages). Anyway (i) they're both being retargeted,
along with Perl, to the parrot runtime[*], AIUI, (ii) ... Larry said
it!


[*] And I *guess* this will greatly improve cross-language
compatibility.


Michele

 

[J. Romano]

JR> Now to my question: Knowing that Perl 6 will have better OO
JR> handling, does that mean that Data:umper will lose its usefulness on
JR> Perl 6 objects? Or will it still be able to let a programmer peer
JR> into them and let him/her tinker with their data using the debugger?

you seem to be conflating data::dumper and OO. dumper is not an OO tool
but a debugging and data tool. i have (as have many others) used it in
many non-oo programs. it is just a way to dump perl data structures (oo
or not) in a way that can be evaled and also read by hyoomans.

Oh, I agree with you there. When I first found out about the
Data:umper module I used it all the time to look at the structures
of complex arrays and hashes. But eventually I found out that it also
works amazingly well with blessed objects.

Now I use it whenever I work with Perl objects, whether I wrote
them or not. Debugging OO code is so much easier with Data:umper
since I don't have to guess about a blessed object's current structure
based on the code that may or may not have been executed.
Data:umper may break the idea of Object-Oriented Information Hiding,
but it's been a wonderful tool for me to use when I venture into the
OO world.

What I'm trying to say is that the Data:umper module was so
well-thought out (in my opinion) that it works just as well with Perl
objects as with non-objects. There is no additional tweaking
necessary on my part to get Data:umper to work on a reference just
because it is blessed. The module knows about blessed references and
is able to create an appropriate string to eval() without ever having
me worry about it.

-- Jean-Luc