Re: Re (tilly) 2: Benchmarks: Costs of OO Perl

You may notice that the latest version makes use of the direct access. Is is Politically correct to access attributes directly if you are in that class? Is there a downside? I understand the hazards of direct access outside of a class but haven't considered internal direct access.

coreolyn

Comment on Re: Re (tilly) 2: Benchmarks: Costs of OO Perl

Replies are listed 'Best First'.
Re (tilly) 4: Benchmarks: Costs of OO Perl by tilly (Archbishop) on Jan 11, 2001 at 05:20 UTC
As far as I am concerned it is not only correct, it is advisable. The principle of encapsulation is that you want to localize assumptions about the internal implementation into one section with a well-defined and simple interface to the outside world. The point of that is so that you can change the implementation if you need to. (Part and parcel of this is that you don't expose any piece of functionality in your interface until you need it. After all the richer your interface, the harder it is to change the implementation.) That does not mean that you intentionally choose an implementation you are likely to want to change. Given the fact that get/set methods are so much slower than direct access of attributes, unless you need the extra flexibility from the start of being able to override the implementation in subclasses, by default start with an implementation that is fast. Another way to put it is design your program so that you can change your implementation at will (and make a practice of doing proactive tweaks from time to time just to keep you aware of things that you do which make those changes hard) but also try to find implementations that you don't think you will want to change...	[reply]

Replies are listed 'Best First'.

Re (tilly) 4: Benchmarks: Costs of OO Perl
by tilly (Archbishop) on Jan 11, 2001 at 05:20 UTC

The principle of encapsulation is that you want to localize assumptions about the internal implementation into one section with a well-defined and simple interface to the outside world. The point of that is so that you can change the implementation if you need to. (Part and parcel of this is that you don't expose any piece of functionality in your interface until you need it. After all the richer your interface, the harder it is to change the implementation.)

That does not mean that you intentionally choose an implementation you are likely to want to change. Given the fact that get/set methods are so much slower than direct access of attributes, unless you need the extra flexibility from the start of being able to override the implementation in subclasses, by default start with an implementation that is fast.

Another way to put it is design your program so that you can change your implementation at will (and make a practice of doing proactive tweaks from time to time just to keep you aware of things that you do which make those changes hard) but also try to find implementations that you don't think you will want to change...

[reply]