Re: Hypothetical: All code in classes but main()
From: Steven T. Hatton (susudata_at_setidava.kushan.aa)
Date: 04/12/04
- Next message: Derek: "Re: Confused about the comma operator"
- Previous message: Jeff Schwab: "Re: Sutter's Pimples: Good, Bad, or Ugly?"
- In reply to: Mark A. Gibbs: "Re: Hypothetical: All code in classes but main()"
- Next in thread: Mark A. Gibbs: "Re: Hypothetical: All code in classes but main()"
- Reply: Mark A. Gibbs: "Re: Hypothetical: All code in classes but main()"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 11 Apr 2004 18:27:25 -0400
Mark A. Gibbs wrote:
>
> Steven T. Hatton wrote:
>
>> Yes it supports the point I was making.
>
> What point? And supports it how? It still makes no sense to me.
The point you think it supports. I was explaining why there is a problem
with implementing the hypothesis.
> I did not say class static functions, I said static functions, which is
> equivalent to globabl functions.
I'm not familiar with that usage. It certainly wasn't what was implied by
the context.
> While you are technically right, that a class static function can access
> all data members, if it needs to access private and protected instance
> members, why is it a class static function?
One reason for having a static member function is to implement a singleton
design pattern.
>From GoF page 129:
The Singleton class is declared as
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
};
The corresponding implementation is
Singleton* Singleton::_instance = 0;
Singleton* Singleton::Instance () {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
> Actually, that brings up another area that you're way out in left field
> on. Public data members. I was actually shaking my head in disbelief at
> your proposed "associated" extension. I have never heard any recommend
> the use of public data members in good OO design.
The suggestion was based on Stroustrup's advice to "[p]refer nonmember
functions over member functions for operations that do not need access to
the representation". And "use namespaces to associate helper functions with
'their' class".
My statement was:
"I actually proposed another access specifier in addition to private,
protected, public and firend. I suggested /associated/ which would allow a
function to be a member, but it would only have access to public members of
its own class."
Observe that I did not specify member *data*, but merely /members/.
> It violates
> encapsulation. I have heard some Java wags claim that for performance
> reasons the cost of the accessor methods can be too much, but even that
> has been debunked as nonsense. Just declare your accessor methods final
> and most compilers will optimize them away.
And what happens to inheritance?
> There are no benefits to public data members except for backwards
> compatability with old C code (and that is not an issue in this
> discussion).
How bout public member functions? But, please take this one up with
Stroustrup. He's the one who made the original recommendation about helper
functions not having unnecessary access to the private and protected
members.
>> If you have a reasonably good IDE its very easy to type:
>> java.[get a listing of available packages and classes]
>
> Oh my lord. Your justification for a restrictive design constraint to be
> applied to an entire body of work is that it makes it easier to make
> flashy IDE's?
No, that wasn't my point. But I have advocated making IDE support a formal
considderation when designing the language.
> But I'll tell you what, I'll play along.
>
> Why is it not possible for a C++ ide to detect a function sin() in a
> namespace math in a namespace top?
Did I say it wasn't?
>> One might argue that the real difference is that in Java you have another
>> level of encapsulation. I find 'free' functions to be of questionable
>> value. Some people seem to think of them as global functions.
>
> There is no other level of encapsulation, encapsulation happens (as it
> does in Java) at the class level. If you expose the guts of your class,
> that is hardly the fault of an external function.
You missed the point.
>> Perhaps. There is the advantage of predictability. That is, since there
>> are fewer options, it's easier to determine how something is structured.
>> It also enforces certain structural rules that programmers might
>> otherwise violate.
>
> I thought the structure was quite clear. All the math functions are in
> the Math namespace.
>
> What you're telling me is that you think having all the math functions
> in the Math class is more structured than having all the math functions
> in the Math namespace. But they're the same thing.
No. It's more structured than std::tanh().
> The price is that I now have to include ALL the math functions in a
> source file, even if I just want sqrt(). Also, if I have 1000+ math
> functions (which is not inconceivable, what with overloads and all), and
> I want to change or add just one,
I would never advocate putting 1000+ functions in a flat structure. But,
for people who think like that, there is really no cure.
> Your point? Some Java programmers believe that public data members are a
> viable option. I wouldn't hire from either group.
As you will:
> (because OO is not exactly written in stone, you know, there are many
> interpretations of the OO gospel), I will point out instead that OO is
> hardly the last word in software design theory. Just search for object
> oriented critiques, and alternatives.
[This response intentionally left blank]
> The problem with that is that you're not using the tools effectively. In
> fact, you're not using the tools at all. Namespace-scope functions are
> tools, too. They are designed to solve a specific problem: operations
> that are not associated with class data. You're tossing the screwdriver
> aside and using the hammer to drive screws.
[This response intentionally left blank]
> And no, I've never wondered why any german thinker for english crockery
> would mean table, and for what. And I'm sure there is a lesson there,
> there are lessons everywhere. The questions should, is it a good lesson?
> And, is it relevant?
It derives from the same Latin word which was a post with an eating surface
on top which the Roman soldiers (Many of whom were Germanic) used. As time
went on, the word came to mean two distinct things in the respective
Germanic languages. The point is that ideas associated with words change
over time, and space. This is especially true if words are used in
evolving fields.
>> One might argue that you have the illusion of choice in C++. How many
>> main() functions can exist in a C++ program? How do you specify the
>> namespace for that function? That sounds like a restraction, not a
>> liberty to me.
>
> There is no illusion. You can have as many main() functions as you want.
> You specify namespaces for main() functions the same way as for any
> other function. You can only have one *entry point*, but that's true for
> Java too (in the least illogical case). The only "restriction" here is
> that the main() function in the global namespace is the entry point.
I meant the main() in the global namespace. There is no point in having a
non-global main() in C++. I simply assumed that was a foregone conclusion,
so I didn't bother to go into the details.
> Java's restriction is no less restricting: the entry point must be a
> static function called main in your startup class. You can have static
> functions called main in other classes if you want. You can have free
> main functions in other namespaces if you want. What's the problem?
But you can call ClassName.main(String[] args), or otherwise use any class
with a function main() without recompiling.
>> I could be argued that /a/ math does have a cosine. But I would tend to
>> argue that for practical purposes, there is only one (singleton) math.
>> Math /is/ actually instantiated implicitly in Java.
>
> It could also be argued that the world is a flat plate resting on the
> back of an infinitely high pile of turtles, and that there are fairies
> whose job it is to catch us when we fall off one side and put us on the
> other and to alter all of our memories and measurements to keep the
> truth from us. That doesn't make it right.
Well, there are different categorizations of the general field of
Mathematics which are called for example Vector Math, Discrete Math,
Applied Math...
> If you really understood object oriented terminology, you'd be laughing
> at the idea of instantiating math. What's next, inheriting from Humour?
> Extending Peace? Overriding Truth?
That is, if I cared to consider any of the foregoing diversion.
>> Yup, you understood the intent. There are some advantages to the
>> functional operator approach to mathematical symbolism.
>
> Unless, of course, you're doing math.
This is just the first hit on a google for "functional operator":
http://nyjm.albany.edu:8000/j/1999/5-12.pdf
> And of course, it doesn't answer the cardinal question. If Java is the
> model that C++ should follow, why does Java keep evolving to look more
> like C++?
Who suggested C++ should be more like Java? The only reason I've been
discussing Java in this context is because it provides a relevant example
of a programming language that requires the *hypothetical* proposition.
-- STH Hatton's Law: "There is only One inviolable Law" KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com Mozilla: http://www.mozilla.org
- Next message: Derek: "Re: Confused about the comma operator"
- Previous message: Jeff Schwab: "Re: Sutter's Pimples: Good, Bad, or Ugly?"
- In reply to: Mark A. Gibbs: "Re: Hypothetical: All code in classes but main()"
- Next in thread: Mark A. Gibbs: "Re: Hypothetical: All code in classes but main()"
- Reply: Mark A. Gibbs: "Re: Hypothetical: All code in classes but main()"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
