in reply to Re^12: Assignable Subroutines
in thread Assignable Subroutines

The "no trivial mutators" idea comes from the fact that if you wanted a struct, then you should have used a struct and left the OO baggage behind.

Java gets stuck on the fact that everything has to be an object, which means that when a struct really is the best way to do something (as it is in many simple programs), you still have to define it in terms of an object. That's an inheirent difficulty in single-paradigm languages.

We don't have that problem in Perl, but it's still good advice that if you're going to trouble yourself with OO, then you should really do OO. I'm not going to demand that you apply OO everywhere, only that if you use it, you use it correctly. Bad OO is often worse than not using it in the first place.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Replies are listed 'Best First'.
Re^14: Assignable Subroutines
by fergal (Chaplain) on Jan 27, 2005 at 20:42 UTC
    Why should I have to choose between struct and object? It's incredibly useful to have both and I still haven't seen an example of anything bad happening when that is done. Look, for example, at Haskell, which uses multiple dispatch, where not only structs have object behaviours but even scalars (which are equivalent to structs with a single field) have too.
[reply]

      You end up having insufficient checks in the object. Actually, I think dragonchild's giveRaise() and givePromotion() methods are better than my solution (these two methods could potentially be implemented with Effects, though I'm not sure why you would want to). In both cases, it's clear from the method name alone what is going to be done.

      Further, there are two different reasons given here for changing the salary of an existing employee, and they both likely have completely different buisness rules behind them. With dragonchild's method, those buisness rules will be completely seperated by two different methods.

      The Effect^H^H^H Visitor Pattern is still applicable in some applications, such as implementing the massive flexibility required by my game framework.

      "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

[reply]
[d/l]
[select]
        You end up having insufficient checks in the object.
        Why do I end up with that? What is stopping me from adding in the extra checks that would make it sufficient? I'm talking about an object that has struct like fields that are only accessible through mutators so I can check anything I like at set time.
[reply]

In Section Meditations