Re^6: The Accessor Heresy

Think "has-a" relationships

Every property is a "has-a" relationiship. A circle "has-an" area. An employee "has-a" salary.

It's the wholesale application of this design even where it makes no sense and costs a lot more than it buys that I disagree with.

Since I didn't endorse the wholesale application of that design, I have no idea why you're disagreeing with it to me.

An "Area" class? What in heaven's name for?

I never suggested that an Area class was, specifically, a good idea. I'm sure you've seen examples before that are not pulled from real world usage.

In other words, it really seems you are saying something like

Of course, I've said nothing of the kind. If you would concern yourself with what I say, rather than what it seems like I'm saying something like, we might both be significantly less annoyed.

if you want to retract most of your original node [...] I will agree with you.

It's not at all clear that you're familiar with the original node. I can't retract most of "what it seems like I'm saying something like." I could only retract something I said. I explained that the usual implementation of accessors is not OO design, and that's why they rankle. I demonstrated what an OO approach would be. You haven't disagreed with any of that.

Caution: Contents may have been coded under pressure.

Comment on Re^6: The Accessor Heresy

Replies are listed 'Best First'.
Re^7: The Accessor Heresy by sauoq (Abbot) on Nov 28, 2005 at 22:19 UTC
Every property is a "has-a" relationiship. A circle "has-an" area. An employee "has-a" salary. So what, exactly? An employee has-a salary therefore you should implement a Salary class? It doesn't follow. In those cases where it makes sense to do this... well... it frequently already is. So, on one hand, you aren't offering anything that isn't already common practice. Since I didn't endorse the wholesale application of that design, I have no idea why you're disagreeing with it to me. You never discussed the conditions under which you think this design would be the right one to use. Instead, you made statements like "I believe I understand what it is that makes accessors rankle so much" and "An OO approach would be to have the properties be 'sub-objects' all of which implies the sweeping generalities that using this technique will make accessors rankle less and be a true "OO approach". Now, don't blame me for reading between the lines. If you want to communicate something different, than do so. Explicitly. Like I said above, on one hand you are offering an approach that is already common practice (though you haven't offered it as a tutorial but more like it was something original.) On the other hand, you are suggesting that this technique is an "OO approach" ostensibly exlcuding the OO-ness of other approaches. Or, at least, recommending more widespread use. Or something. Certainly you offer it as some sort of cure for rankling accessors, though you don't really cure anything by just adding another object in the chain to those accessors. Afterall, you still end up with `...->set(5)`. I never suggested that an Area class was, specifically, a good idea. I'm sure you've seen examples before that are not pulled from real world usage. Sure, but you never deigned to talk about the drawbacks of your example either. Nor what exactly you were attempting to illustrate. You just wrap an attribute up in a class and call it a good thing. That's why I called it useless abstraction. Of course, I've said nothing of the kind. If you would concern yourself with what I say, rather than what it seems like I'm saying something like, we might both be significantly less annoyed. I haven't really been all that annoyed up until now. So, you're the perfect communicator here, right? And anyone who has a perception of what it is you are saying is somehow at fault for not reading your mind? All right, Roy, here's what I think: the practice of wrapping accessors up as objects simply for the sake of making things more "OO" is about as ridiculous a notion I've heard in quite some time and I can't imagine why anyone would think it deserving of an meditation. I explained that the usual implementation of accessors is not OO design, and that's why they rankle. I demonstrated what an OO approach would be. You haven't disagreed with any of that. Actually, I've disagreed with all of that. Particular with the claim that you've demonstrated an OO approach. Perl isn't an OO language. You haven't escaped from that fact. It doesn't matter if you use `$foo->set_baz(42)` or `$foo->bar->baz->set(42)`, you are still using "42" and, in Perl, that's not an object. -sauoq "My two cents aren't worth a dime.";	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^7: The Accessor Heresy
by sauoq (Abbot) on Nov 28, 2005 at 22:19 UTC

Every property is a "has-a" relationiship. A circle "has-an" area. An employee "has-a" salary.

So what, exactly? An employee has-a salary therefore you should implement a Salary class? It doesn't follow. In those cases where it makes sense to do this... well... it frequently already is. So, on one hand, you aren't offering anything that isn't already common practice.

Since I didn't endorse the wholesale application of that design, I have no idea why you're disagreeing with it to me.

You never discussed the conditions under which you think this design would be the right one to use. Instead, you made statements like "I believe I understand what it is that makes accessors rankle so much" and "An OO approach would be to have the properties be 'sub-objects' all of which implies the sweeping generalities that using this technique will make accessors rankle less and be a true "OO approach".

Now, don't blame me for reading between the lines. If you want to communicate something different, than do so. Explicitly.

Like I said above, on one hand you are offering an approach that is already common practice (though you haven't offered it as a tutorial but more like it was something original.) On the other hand, you are suggesting that this technique is an "OO approach" ostensibly exlcuding the OO-ness of other approaches. Or, at least, recommending more widespread use. Or something. Certainly you offer it as some sort of cure for rankling accessors, though you don't really cure anything by just adding another object in the chain to those accessors. Afterall, you still end up with ...->set(5).

I never suggested that an Area class was, specifically, a good idea. I'm sure you've seen examples before that are not pulled from real world usage.

Sure, but you never deigned to talk about the drawbacks of your example either. Nor what exactly you were attempting to illustrate. You just wrap an attribute up in a class and call it a good thing. That's why I called it useless abstraction.

Of course, I've said nothing of the kind. If you would concern yourself with what I say, rather than what it seems like I'm saying something like, we might both be significantly less annoyed.

I haven't really been all that annoyed up until now. So, you're the perfect communicator here, right? And anyone who has a perception of what it is you are saying is somehow at fault for not reading your mind? All right, Roy, here's what I think: the practice of wrapping accessors up as objects simply for the sake of making things more "OO" is about as ridiculous a notion I've heard in quite some time and I can't imagine why anyone would think it deserving of an meditation.

I explained that the usual implementation of accessors is not OO design, and that's why they rankle. I demonstrated what an OO approach would be. You haven't disagreed with any of that.

Actually, I've disagreed with all of that. Particular with the claim that you've demonstrated an OO approach. Perl isn't an OO language. You haven't escaped from that fact. It doesn't matter if you use $foo->set_baz(42) or $foo->bar->baz->set(42), you are still using "42" and, in Perl, that's not an object.

-sauoq
"My two cents aren't worth a dime.";

[reply]
[d/l]
[select]