I don't understand what you mean by "higher up".

I mean the code to handle this is lifted outside the class and into the caller.

It's in the caller in your code too, it's just all stuffed into an effect object which is created and applied by the caller and I still haven't seen an example of why that might cause a problem.

I, for one, like the addition of small, domain specific languages. Your choice is to either learn an API or learn a (small) language. Choosing one or the other tends to force you twards different design decisions, but the cost of learning is not so different.

Yes they're great but I have 2 problems with your.

• It's domain is already completely covered by Perl
• Your language has to be typed in as a structure that represents a parsed syntax tree which is not so convient

If you want to continue use it fine but I really recommend looking at Tangram, the techniques in there would allow you to replace

my $effect = Effect->new(
    [ salary    => 1.02, '*' ],
    [ frobnitz  => 1.5, '+'  ],
);
$_->apply_effect( $effect ) for @employees;
[download]

with

my $effect = Effect->new;
$effect->salary *= 1.02;
$effect->frobnitz += 1.5;

$_->apply_effect( $effect ) for @employees;
[download]

which may not look so different but because it's actual Perl it requires no learning at all. It also would allow stuff like

$effect->salary = $effect->frobnitz + 1.5;
[download]

Encapsulation is hiding data and behavior. Applying trvial mutators exposes data. It's therefore bad encapsulation. QED.

That's exactly the circular logic I was talking about. Your using your own definition of encapsulation to to justify itself. You've basically said "it's not my kind of encapsulation therefore it's bad encapsulation".

For me, encapsulation does not mean hiding all data it just means hiding particular pieces of data from particular parts of the program. In many situations, some data really does need to be exposed but by exposing the data through methods you are not breaking encapsulation because the actual internal data is still guarded from direct manipulation.

You keep talking about trivial mutators. Are non-trivial ones OK? If so what should I do if I change my implementation so that a non-trivial mutator is now trivial?

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.