Re: Trying to understand Perl Objects

If you really have to create a complex datastructure to store all this, and then bless it much of the benefits with using objects will disepear.

How so? People use objects for many reasons, but one of the most important is the ability to bundle together data and the methods that use that data. You can still closely bundle data and process when data is stored in a hash. Since any pure scalar or reference can be stored as a hash value, you can store any type of variable needed by your methods: strings, numbers, file handles, compiled regular expressions, code references, array references, hash references, and even references to other objects.

I can not have an perl5-object with more then one instance variable without using a hash

Not so. You can bless any reference, including an array reference. Some people prefer to construct their objects using blessed array references. They feel it makes the object a little more opaque - unlike hash keys there is nothing in an array to indicate which variable has which meaning, thus making it harder to bypass accessor methods to get at data. Personally, I prefer a blessed hash with a member for each variable I want to store, but to each his own.

Best, beth

Comment on Re: Trying to understand Perl Objects

Replies are listed 'Best First'.
Re^2: Trying to understand Perl Objects by JadeNB (Chaplain) on Apr 04, 2009 at 21:19 UTC
Some people prefer to construct their objects using blessed array references. They feel it makes the object a little more opaque - unlike hash keys there is nothing in an array to indicate which variable has which meaning, thus making it harder to bypass accessor methods to get at data. Is this really a reason that people use blessed arrayrefs? I always thought that it was for speed. Every object that I've ever seen structured this way got at the entries of the arrays by using named constants as indices, which would remove any “benefit” of opacity.	[reply]
Re^2: Trying to understand Perl Objects by stvn (Monsignor) on Apr 07, 2009 at 00:35 UTC
Some people prefer to construct their objects using blessed array references. They feel it makes the object a little more opaque - unlike hash keys there is nothing in an array to indicate which variable has which meaning, thus making it harder to bypass accessor methods to get at data. I have never heard this rationale before, but it smells of "Security through obscurity" rather then any real solid reasoning. The most widely used array-based OOP module I know of is POE and that choice was made very specifically because of performance. Of course this was like 1999 performance, so how applicable that still is on modern systems I don't know. -stvn	[reply]
Re^2: Trying to understand Perl Objects by plobsing (Friar) on Apr 07, 2009 at 03:18 UTC
When I used to roll my own OO, I would do this. I liked it because it (in combination with strictures) gave me compile time errors when I made a typo in a field name. With a similar error using a vanilla hash, you just keep getting undef or setting something that never gets read. I didn't consider it opaque. All the fields in the object are nicely listed at the top of the module in a constant/enum statement. I never roll my own OO anymore. Also, I realize now that low-level field access in enough places to make the above argument valid is probably a bad sign.	[reply]