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

The restrictions are why people call them "references" instead of 
"pointers", just like you call them "pointers" instead of "addresses" 
because they can only point to one type of object. I.e., you can have an 
integer and a float at the same address, but you can't have one pointer 
that points to either of those. (And no, "void*" doesn't count void* 
points to neither, not either.)

It's really just a precision-in-terminology thing for people who make 
such distinctions in their everyday work of designing languages. :-)

>>  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?

Sure you can. C# has the same public/private/protected/<mumble> that C++ 
has. With the added advantage that private variables really are private.

(There's one more access class that I forget what it is, but it means 
basically visible across compilation units but not across "assemblies", 
where an "assembly" is a unit of distribution of object code, like a 
library or component. So you can have a type that's private to your 
entire graphics library, usable from everywhere inside the graphics lib 
without being visible outside it.)

>   This removes clutter from the AClass definition.

In C#, you don't have to do anything like that. You declare AClass as 
public, AClass::Inner as private, and you're done. You don't have to 
pick different files to put them in to enforce who gets to see them.

Nor, for that matter, do you need to do anything funky with private 
member variables in a class. If you don't give someone the source code, 
they don't see the private variables.

>   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.)

Well, in the cases where this is used, they're "properties" of the 
object. If you're setting whether the printer will print in color or 
not, you use a "property" and C# writes the setter and getter routines 
for you. It's not exposing a member variable - that's the point of 
making it a property.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message