Best C++ game programming book recommendations - Other Technologies

> I don't see why this should be the case. In C++, you can put all of the
> elements of the namespace in a single file.

In theory, yes. In practice they're usually distributed. In addition,
with namespaces you cannot guarantee encapsulation in the sense of
marking out a bounds to the functionality as any new code can
arbitrarily extend the namespace. Therefore your 'encapsulation' is
arbitrarily bound and you can offer no real guard or bounds (which are
concepts which are bound up in what I think "encapsulation" means)

> In Java you can't

Oooh! You bully!

, which is why
> you often find Java classes being abused as namespaces (to the detriment of
> encapsulation).

Case in point?

In article <_aM0c.5176$rb.63636@news.indigo.ie>, gerryq@indigo.ie
says...
> [...]
> What is that 0.5, sitting out among the global functions? Why it's a
> variable telling Wombat how long to nap for!

Um, no Gerry, 0.5 would be a constant, not a variable.


> This is not encapsulation, it's the opposite of encapsulation!

Meyers makes it clear that "nap" belongs to the _convenience_ functions
commonly used by Wombat clients. Napping is not a core function of a
Wombat; sleeping for a specified amount of time is. Why should
any and all convenience functions be encapsulated?


> Wombats have an ability to nap, and the variable saying how long
> they should nap for ought to be encapsulated inside Wombat.

No, at the core, Wombats have an ability to _sleep_ for some
specified amount of time. Meyers example is that many (but not
all) Wombat clients sleep for 0.5 thus adding the convenience
function "nap" for this. nap should not be added to the class,
because its a convenience function that does not need private
access to the Wombat state.

To make the point ridiculously clear, say you have a program
with 100 individual Wombat clients. You identify 10000 different
subsets of these clients, 10 clients each, with each subset
using some core class functions (say eat and sleep) in a
particular way, similar to nap using sleep(0.5).

We now have the option of either a) adding 10000 convenience
functions to the Wombat class interface (which is the implication
of the position you are arguing for) or b) adding 10000 convenience
functions to a namespace outside the Wombat class (which is what
Meyers is saying). Do you really think the former is better
encapsulation?


BTW, here's another C++ expert chiming in on the issue:

http://www.gotw.ca/gotw/084.htm

I guess he's gone "mad" too, right? (Since he agrees with
Meyers and Alexandrescu.)

Also, you might want to read this article of Alexandrescu's,
as I think it better states what he stands for (and contains
his interpretation of Meyers' article):

http://groups.google.com/groups?selm....supernews.com



Christer Ericson
Sony Computer Entertainment, Santa Monica

Peter Ashford wrote:

> > In Java you can't
>
> Oooh! You bully!
>
> > ..., which is why
> > you often find Java classes being abused as namespaces (to the
> > detriment of
> > encapsulation).
>
> Case in point?

I would think that Java packages would be the appropriate construct for
this role, no?

--
__ Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
\__/ You are in the music / In the man's car next to me
-- Sade

Erik Max Francis wrote:

> Peter Ashford wrote:
>
>
>>>In Java you can't
>>
>>Oooh! You bully!
>>
>>
>>>..., which is why
>>>you often find Java classes being abused as namespaces (to the
>>>detriment of
>>>encapsulation).
>>
>>Case in point?
>
>
> I would think that Java packages would be the appropriate construct for
> this role, no?
>

Are you saying that Java packages are being abused as namespaces, or
disagreeing with Rainer?

Peter Ashford wrote:
> Yes. As soon as you recognise that you have wandered into the area of
> "taste" you need to realise that you're done (unless you can get
> someone
> else to accept your intuitions - which is seldom the case if they're
> arguing a different line on a moral/aesthetic issue in the first
> place)

Scott Meyers' and Andrei Alexandrescu's arguments against member functions
are based on technical merit, not "taste". If your sole argument against
them is based on taste, then you're being irrational.


--
Rainer Deyke - rainerd@eldwood.com - http://eldwood.com

Erik Max Francis wrote:
> I would think that Java packages would be the appropriate construct
> for this role, no?

Unfortunately Java packages can only contain classes, not functions or
constants.


--
Rainer Deyke - rainerd@eldwood.com - http://eldwood.com

Peter Ashford wrote:
>> I don't see why this should be the case. In C++, you can put all of
>> the elements of the namespace in a single file.
>
> In theory, yes. In practice they're usually distributed.

In practice, people do all sorts of silly things. That's not much of an
argument.

> In
> addition,
> with namespaces you cannot guarantee encapsulation in the sense of
> marking out a bounds to the functionality as any new code can
> arbitrarily extend the namespace.

Since we're talking about convenience functions, that's hardly a
disadvantage. Let's say we want wombats to be able to take a longer nap.

namespace wombats {

void long_nap(wombat& w)
{
w.sleep(0.75);
}

}

> Therefore your 'encapsulation' is
> arbitrarily bound and you can offer no real guard or bounds (which are
> concepts which are bound up in what I think "encapsulation" means)

Once again, you are confusing the concepts of grouped functionality and
encapsulation. Namespaces offer the former; classes should focus on the
latter. Changes to the implementation of wombat have no effect on other
members of the wombats namespace because they are encapsulated in the wombat
class. Therefore there is no need to protect the wombats namespace from
further additions.


--
Rainer Deyke - rainerd@eldwood.com - http://eldwood.com

Rainer Deyke wrote:

> Peter Ashford wrote:
>
>>Yes. As soon as you recognise that you have wandered into the area of
>>"taste" you need to realise that you're done (unless you can get
>>someone
>>else to accept your intuitions - which is seldom the case if they're
>>arguing a different line on a moral/aesthetic issue in the first
>>place)
>
>
> Scott Meyers' and Andrei Alexandrescu's arguments against member functions
> are based on technical merit, not "taste". If your sole argument against
> them is based on taste, then you're being irrational.

Dont get personal Rainer.

Rainer Deyke wrote:

> Erik Max Francis wrote:
>
>>I would think that Java packages would be the appropriate construct
>>for this role, no?
>
>
> Unfortunately Java packages can only contain classes, not functions or
> constants.
>
>

Constants in Java always have a class scope, so constants *can* be
included in packages, and obviously they won't include functions since
Java does not have global functions. Also, given that the whole debate
is about the need for external functions, you're begging the question by
excluding Java packages as a solution on the basis on not including
external functions.