|Problems? Is your data what you think it is?|
Re^2: Object oriented Perl and Java: A brief examination of design.by hippo (Curate)
|on Jan 29, 2014 at 09:49 UTC||Need Help??|
For clarity, instance variables are defined within methods and while in many classes they are all defined in the constructor (method) this is not always so.
Most OO Perl programmes are today written using Moose, Moo, Mouse, etc.
I'm sure that many are - but "most"? Do you have any data to back this up? I've been using Moo on and off for a couple of years and have just returned to it in the last week or so. Building a class using the current docs I find that my version of the module is now out of date but that doing the upgrade requires a whole heap of work because of all the (mostly new) dependencies which also serves to reinforce how heavy it is, despite a contrary statement of its aims.
We don't all write daemons or other persistent code where startup time is not a consideration. We don't all have swathes of memory at our disposal to fill with cascades of module dependencies. We don't all have deployment environments where module upgrades can be made with impunity. At least, not all the time :)
The "modern" OO module frameworks such as these are a boon for sure, but they are not a panacea. And while they are probably the simplest, easiest introduction to Perl OO for java programmers like the anonymous OP, if they hide what's going on under the bonnet (or the programmer never thinks to look) the lack of appreciation of the OO core will always hold the programmer back.
Those of us who can remember the introduction of OO into Perl will have been writing such bare-bones code for a decade or more. Many of us still do. While the resulting source may have a little too much boilerplate for some tastes, it will be fast, light and portable.
In summary, it's horses for courses. Learn both approaches, take the best from each and choose from that experience which to apply in relevant situations.
I'll get off my soapbox now. Thank you for listening.