Chambers <ben### [at] pacificwebguycom> wrote:
> 1) The designers have decided that Garbage Collection is a Good 
> Thing(tm), and that pointers are Dangerous.  So, while it's actually 
> possible to use pointers, they spend a lot of time telling you not to.

  That depends on your definition of "pointer".

  In my books Java references *are* pointers. They may have some restrictions
compared to, for example, C pointers, but they are pointers nevertheless.

  What is it that makes it a pointer? Easy: If you do an "a = b;", does
the object get copied, or do now 'a' and 'b' refer to the same object?

> I have to wonder, is the whole debate about GC merely due to the fact 
> that current implementations aren't satisfactory?  If there were better 
> implementations that were more predictable about object destruction and 
> memory cleanup, and especially about when they clean up the fragmented 
> memory space, would developers be more willing to live with it?

  GC is ok most of the time. However, there are situations where it may
have negative effects, as I commented in the other post.

> In fact, 10 years from now, is the debate over GC going to seem like the 
> debate between C and C++: sure, C can be faster, but for most developers 
> the benefits of C++ outweigh the negligible speed penalty.

  "C is faster than C++" is a persistent myth. This has never been so.

> 2) WHY is it considered a Good Thing that class methods must be written 
> inline?

  Beats me.

>  The language doesn't allow class prototypes, and claims this is 
> a benefit because "header files aren't necessary."

  This sounds like a hindrance to modularity. I assume that you can't
have types, functions and variables which are local to a compilation unit
and are completely invisible to the outside?

  In C++ I use this a lot. Not only do I try to make the public interface
of a class (or module) as minimal as possible, I also try to make the
private part as small as possible too. If something is only used by this
class, but it can be moved out of the class, I do so: I move it inside
the compilation unit where that class is implemented. Even if something
is inside this class, for example an inner class, if I can I only
pre-declare that inner class and declare/implement it in the compilation
unit. That is, for example like this:

// AClass.hh
// ---------
class AClass
{
 public:
    ...

 private:
    class InnerClass;
    ...
};

// AClass.cc
// ---------
class AClass::InnerClass
{
    // Implementation of InnerClass here.
};

  This removes clutter from the AClass definition.

> 4) Lastly, sometimes it's the little things that count.  Personally, I 
> love the fact that I don't have to right 'get' and 'set' functions for 
> member variables, even when accessing the data is not straightforward.

> Basically, C# allows you to give any member variable implicit get / set 
> functions that are called when you access the variable normally.

  Some would argue that's exposing the class' internal structure (even if the
variable is not *really* public), and thus it's against good OO principles.

  Usually one should completely avoid get and set methods for member
variables. (Granted, this is not always possible, but in a well-designed
program it can usually be mostly avoided.)

-- 
                                                          - Warp

Post a reply to this message