PM>> A C++ constructor can fail, so in that regard it's more like your init()

 PM>> than your default(). While it's true that a constructor can't return

 PM>> anything, there are other ways of reporting errors.



 PM>> I don't have an equivalent to your Defaults() as I've haven't seen any

 PM>> benefit in it.



 PE> It's for emulating a constructor that can't fail.  You can use it to set

 PE> some "global" variables or something such as the default
zone.  I agree

 PE> that it is debatable how useful this is.



Why use it then?



 PM>> The problem with constructors (and destructors for that matter) is that

 PM>> they are often called outside of your control so there's no way to get

 PM>> at a return value. For instance, given the following declaration how

 PM>> would you report an error?



 PM>> String x = "Hello";



 PE> With great difficulty, which is why I don't allow constuctors to fail.



Since you're using C and not C++, you must call your constructor
explicitly. Therefore you can test the return value all of the time.



It's only under C++ where the compiler can call the constructor behind you
back that you have a problem. That's why they now have exceptions.



 PM>>> I feel that making things private

 PM>>> is the better approach as it discourages fiddling with the
internals of

 PM>>> the class.



 PE>> When was the last time you saw code that manipulated elements of

 PE>> the FILE data type?  There are millions and billions of programs

 PE>> that use the FILE data type, which at least last time I looked at

 PE>> (Watcom I think) was public, but I've yet to see anyone stupid

 PE>> enough to manipulate the internals of the FILE class.  Who are you

 PE>> trying to protect?  You've hired the wrong people if they're

 PE>> manipulating stuff in a structure such as FILE.  And Cobol would

 PE>> be a better language for such people, IMO.



 PM>> It's not just updating the members of a structure I'm trying to

 PM>> discourage, it's also reading them and relying on things that may

 PM>> change. One of the tenets of OO is that the interface should remain the

 PM>> same, but the implementation can change.



 PE> When was the last time you saw a program that relied on the internals of

 PE> the FILE data structure?  So long as you document the interface, which

 PE> fopen(), fgets() etc do, it's people's only silly fault for looking

 PE> inside the FILE data structure.



Why do you think OO languages have the concept of private data?





Paul



--- GoldED 2.42.G0214+