Re: Hypothetical: All code in classes but main()

From: Steven T. Hatton (susudata_at_setidava.kushan.aa)
Date: 04/11/04 

Date: Sun, 11 Apr 2004 03:07:27 -0400

Mark A. Gibbs wrote:

> If you want an operation a @ b to be valid for
> objects of type A and B in any order you either have to define
> operator@(A) in B and operator@(B) in A (thus coupling the two), or
> define operator@(B) in A and operator@(A,B) globally (still coupling the
> two), or define operator@(A,B) and operator@(B,A) globally (leaving the
> classes uncoupled). To me, this *supports* non-class functions.

My point exactly. Though I'm not sure there isn't a third approach which
might actually address the situation better than either of the two shown
above.
 
> Your second argument, if I understood it, makes no sense. "Another
> problem is the fact that functions which were external to a class now
> gain access to member data and potentially become bound to it. This is
> the argument Stroustrup gives for having helper functions at namespace
> scope." So does that support your argument or not?

Yes it supports the point I was making.

> If a function requires access to member data, then by all means make it
> a member function. But static functions can't access member data, now
> can they?

Of course they can.
 
>>
>> As you correctly pointed out below, virtual function calls have some
>> overhead beyond static calls. A static call to a member should be just
>> as fast as a global 'C'-style call, as far as I know.
>
> That is the idea. It is possible for a theoretical implementation to do
> something different, I suppose, but for all practical purposes it is
> safe to assume that the only functional difference between a global
> function and a class static function is that that the class static
> function has access to private and protected class static data and
> functions.

A static function has access to all member data. Am I missing something
here? I only have a couple months of real C++ experience, so I may have
misunderstood something, but I'm almost certain a static member function
can access all member data of instances of the class.
 
> Being a former soldier myself, I should point out that while uniformity
> is generally a good thing, there are many different types of soldiers,
> some specializing in airborne drops, some specializing in beach
> landings, not to mention the wildly varying trades like pilots,
> artillery, armoured, mechanized infantry etc. etc. etc.

But there are certain attributes every solder shares with all others.
Ironically, the model I used for notions of inheritance when first learning
about the concepts of OO was the military organizational structure. There
were no OO programming languages available to the average user at the time.
 
>>>int larger = Math::max(1, 2);
>>>
>>>Only Java programmers could find the latter more legible.
>>
>>
>> There are advantages to having the static Math class in Java. It provides
>> for an easy point of reference. It's kind of like having a directory
>> structure and using it to organize your data. Personally, the following
>> is
>
> ?

If you have a reasonably good IDE its very easy to type:
java.[get a listing of available packages and classes]

select

java.Math.[get a listing of available members with their type displayed]

select what you want.

If you don't like the fully qualified name in the body of your source, just
type /Math.operation(arguments)/, highlight it (it will be displayed with
an indication that the IDE doesn't know about /Math/) hit a specific key
combination to invoke the display of all candidates available in your
classpath. Select java.lang.Math from the list, and it is #imported in the
heading of the source file.
 
If you don't have an IDE just use bash to hook into the same support
features the IDE uses to search the classpath, and to display member
signatures, etc. It's a bit more work, but with a few scripts, it really
is quite easy.

> You could replace "static Math class in Java" with "Math namespace in
> C++" in your statement, and it would still be valid. The *only* reason
> there is a static Math class in Java (as opposed to a Math namespace) is
> that Java does not support free functions.

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.

> Given that C++ has the option, what are the advantages here?

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.

>>>Both can run just as fast (if you inline the former; the latter is
>>>intrinsically inlined), so it's not a speed issue. Namespace Math::max
>>>provides (essentially) the same amount of collision protection and
>>>encapsulation as class Math::max, so it's not a maintennance issue.
>>
>>
>> Other than the fact that people tend to be sloppy with namespaces.
>
> People can be just as sloppy with anything in C++, and it's usually the
> same people. Is there any emperical evidence that people tend to
> sloppiness when namespaces are introduced?

The STL.
 
> But let me give the benefit of the doubt and ask sloppy in what way?
>
>>>What it is, is a design issue. What you're telling me is that there are
>>>such things as "Math" objects.
>>
>>
>> No. It's saying there are mathematical operators which can be classified
>> as such.
>
> Yes, but there are many ways of doing this in C++. You could use a
> "Math" class, or you could use a "Math" namespace, or you could prefix
> global functions with "Math_".

And (some) C++ programmers believe the last is a viable option.

> Each of these methods groups certain
> operations together, and each tell me different things about that
> grouping. The class tells me that "Math"'s are things, ie, objects -
> it's not called object-oriented programming for giggles - just like
> class Student, class smart_ptr_policy or class ifstream. The namespace
> tells me that these functions are conceptually grouped in some way, but
> otherwise gives me no further indications of how - which is fine, all I
> really need to understand is that they are all "Math" functions.

But when you have disorganized your collection of operators as described
above, it is more difficult to work with. As far as OO goes, if you really
understand what Java is doing, you would understand that it is very much OO
to do things that way. But even if you only look at the surface, there is
nothing non-OO about using utilities classes. It's just another way of
using tools effectively.

> Of course I understand that, it was my argument after all. But a class
> describes a (surprise, surprise) class of objects.

So if there is only one instance of a class, does that mean OO has been
missused? I find that argument against the use of the Math class to be
silly. Ever wonder why the German cognate for the English /dish/ means
table? There is a lesson there.

> The ONLY valid
> reasons I can think of for having a non-instantiable (static) class is
> when that body of operations MUST NOT be extended, and/or they all make
> use of some kind of private data/algorithms that MUST NOT be visible to
> the rest of the program.

I tend to believe the onus falls in the other direction as far as the
visibility of data. But that's just what the standard texts on OO say.
 
> As I mentioned before, Java has no choice but to do max() with static
> class members. You have a choice in C++.

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.
 
> Let me make this absolutely clear. I believe there is no difference
> between designs that use non-class-functions and those that do in terms
> of functionality, efficiency and maintainability. If anyone disagrees,
> let me know. As far as I'm concerned this discussion is over the
> benefits of Class::function() vs. Namespace::function(), and nothing more.

That was what I was intending in the immediate discussion. My inclination is
to view namespaces as fairly unstructured in comparison to classes.

> So to answer what I think your question was: it doesn't. It's the same
> damn thing. There are no functional benefits either way.
>
> But to me at least, you are making a statement when you create a class
> vs. a namespace. A class describes a "thing", an object. A namespace
> describes a group. To me, mathematical operations can be grouped. But a
> "Math" doesn't have a "cosh()" capability.

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.

> Do not try to bend the Math into an object. That is impossible. Instead,
> try to remember the truth.

I don't find that to be a compelling argument. The name Math is just a
shorthand for mathematical utilities. It works reasonably well. I was
horrified when I first saw Java's vecmath (well actually it took a few days
for the horror to sink in). There are some things that are simply awkward
in it. Operator overloading would, perhaps, be a welcome enhancement, but
when I simply accepted it for what it was, a lot of the superficial
objections came to appear irrelevant.
 
> There is no Math.

I sure have a lot of math books about nothing then.
 
>>>Doesn't the latter just make more sense?
>>
>>
>> It depends how it's managed. Java takes the functional operator approach
>> to
>> mathematical syntax, whereas C++ allows for infix notation. I find that
>> far more significant in terms of how it 'feels' to use. An interesting
>> parallel to this is found in Misner, Thorne and Wheeler's _Gravitation_
>> where three notational forms are used in parallel through out the text:
>>
>> http://www.reviewcentre.com/review57645.html
>
> wha?
>
> [Attempting to decode]
>
> If you prefer to use functional notation as opposed to operators, go
> nuts. I think a + b is more understandable than operator+(a, b), but
> hey, that's me.

Yup, you understood the intent. There are some advantages to the functional
operator approach to mathematical symbolism.

> I understand that it was hypothetical, so was my proposed "morse coding
> standard".

Can you provide an example of a successfull general purpose programming
language that used such an approach?

> I am learning here, too. If you can convince me that
> class-only design is better in some way than using global functions,

I could rest my case right here.

> So tell me what you mean by "easier" refactoring or reuse, and how a
> collection of static class functions makes this possible over a namespace.

If you read my comment about namespaces you may notice I already addressed
that. But, namespaces do have on additional drawback in that they are can
easily be concatanated, sometimes in less than obvious ways.

> For the record, Java is designed to run in distributed and network
> environments. Because of the constraints of this environment, everything
> *has* to be a class. They didn't make class Math cause it was a good
> idea. They did it cause they needed the functions and had no other way
> to make them.

I'm not sure of all the cause and effect, but, yes, Java pretty much forces
the creation of Math. There, of course, are a few alternatives, such as
making a class for each operator, or for some subset of operators. I'll
grant that Java lacks a lot of the available finesse in C++. But that
feature of C++ comes at a cost. 

-- 
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

Relevant Pages

  • Re: Hypothetical: All code in classes but main()
    ... >>gain access to member data and potentially become bound to it. ... >>the argument Stroustrup gives for having helper functions at namespace ... I have heard some Java wags claim that for performance ... Then I click on the "math" namespace, and the box refreshes, now ...
    (comp.lang.cpp)
  • Re: Hypothetical: All code in classes but main()
    ... the argument Stroustrup gives for having helper functions at namespace ... If a function requires access to member data, then by all means make it ... > There are advantages to having the static Math class in Java. ...
    (comp.lang.cpp)
  • Re: C++, C# or Java.
    ... The operator notation gets more and more appealing the more you chain ... It looks more like math. ... more opaque than postfix when you nest. ... Java is like the Roman ...
    (comp.lang.java.programmer)
  • Re: Problems I have with 1.999...=2
    ... nine tenths plus nine hundredths plus nine ... The preceding post is perfectly attentive. ... If you are here to understand math - then try to understand what ... >member of the described set, ...
    (sci.math)
  • Re: Bloody Java again
    ... have any trouble with this calculus stuff. ... My experience with discrete math was awful. ... Java who has written a book about Java himself. ... As an example only 1 other of the 4 mature students that were ...
    (comp.lang.functional)