in reply to Re^5: OO Getters/Setters
in thread OO Getters/Setters

Accessors/mutators, by definition, provide direct access to the underlieing attributes. Since Perl is a dynamically typed language, that means doing any sort of validation on the data makes it something other than an accessor/mutator.

Pedantry such as this seems useless to me. If the object's interface says the only way to access an attribute is by using method foo, then for all intents and purposes, foo is an accessor. Believing anything else pierces the veil of encapsulation and defeats one of the main purposes of object orientation.

Ah, but now I'm into the fray... Quick! What's a "block structured language" and why is C not one of them? For bonus points, how does the fact that C is not block structured affect your ability to write useful applications?

duff

Replies are listed 'Best First'.
Re^7: OO Getters/Setters
by hardburn (Abbot) on Dec 31, 2003 at 17:20 UTC

    Pedantry such as this seems useless to me.

    No, I think the distinction is important. If your interface provides direct access to the attribute, it's not encapsulating anything, and thus breaking the foundations of OO design. That doesn't automatically make it bad, but it often is.

    Quick! What's a "block structured language" and why is C not one of them?

    This isn't something I've encountered before. But with a little help from Google . . .

    Block structured languages allow you to have functions nested inside other functions. C/C++ doesn't allow this, which means all those great tricks with closures in Perl and similar languages can't be done.

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

[reply]
[d/l]
      C/C++ doesn't allow this, which means all those great tricks with closures in Perl and similar languages can't be done.

      Pshaw. Go look in stdlib.h and figure out how qsort manages to call a function through a pointer to that function.

      That is the key element to figuring out how to do anything that you can do with closures. What C won't do for you is bind an environment around a pointer to a function, or do your memory management for you. But nothing stops you from defining a struct that contains a pointer to a function and a pointer to an environment variable, and then a function that takes said struct and an argument, then calls the anonymous function passing in both environment and argument.

      With some elbow grease you can then code by hand literally anything that you can do with closures. With the right macros you can hide most of the ugliness.

      And if you don't want to do your own memory management, then don't.

[reply]
      If your interface provides direct access to the attribute, it's not encapsulating anything, and thus breaking the foundations of OO design. That doesn't automatically make it bad, but it often is.

      Hmm. I think we're in violent agreement, but our minds don't share the same map for "accessor/mutator". I think of them as "object state retriever/alterer" methods while you appear to think of them as "object attribute retriever/alterer" methods. The difference is subtle but important as an object's state is spread out over all of its attributes (and occasionally its methods too). I suppose your usage is more commensurate with the literature though.

      duff

[reply]

In Section Seekers of Perl Wisdom