Re^7: OO Getters/Setters

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

Comment on Re^7: OO Getters/Setters Download Code

Replies are listed 'Best First'.
Re: Re^7: OO Getters/Setters by tilly (Archbishop) on Dec 31, 2003 at 22:11 UTC
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]
Re: Re^7: OO Getters/Setters by duff (Parson) on Dec 31, 2003 at 18:05 UTC
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]