On Thu, Mar 13, 2003 at 01:07:31AM +0100, Andreas Happe wrote: > >Either: > >1) Declare everything public, and comments to the class declaration saying > >"don't call this function" or "for internal use only" or words to that > >effect. Data hiding isn't needed when you trust the people using your code > >:-) > > where's the advantage over a structure with pointer to functions (except > inheritance, which could be emulated, no I don't like vpointer tables ;))
Functionally, there is none. It's a straightforward transition from what Ion's using at the moment. The advantage is that you can let the language do much of the housekeeping for you, so you can concentrate on other things. > I've access protection is not needed it should never get into ion. As > i've stated before it is possible to create object oriented programms > without using oo languages. Agreed. OOP is _possible_ in any sensible language (Turbo Assembler supported OOP, back in the day). The difference is whether it's _easy_ or _hard_. All the evidence is that in C it's _hard_ and _messy_ (case study: gtk) and in C++ it's _easier_ and _less messy_ (case study: Qt). [Off topic: If you _really_ want to do OOP then experience the wonders of Ruby and Smalltalk. I use Ruby a lot and reckon that one line of Ruby is worth ~100 lines of C++ and ~250 lines of C.] > Another question is how much the performance disadvantage of those > access checks would be, but as there's at least one widly known window > manager ((black|flux|open)box) family out there this can't be _that_ > problem. These checks are enforced at compile time in C++ so there is no penalty. Access checks exist so that you can create a well defined interface between two bits of code and ensure that this interface is adhered to. This is important if, for example, you're writing a library that's going to be used by lots of other people and you want the freedom to change the internals of your library without breaking other people's code. But Ion doesn't interface to anything but itself and maybe a couple of modules so access checks are a design overkill. Regards, Tom
