Re: broken oop ?



On Mon, 17 May 1999, Sergio A. Kessler wrote:

> >This will be really really slow compared to direct access.
> 
> C'mon Elliot...
> 
> Isn't the rigth thing to provide accesors ?
> At least as macros as Miguel suggested ?

Macros may make sense...

> If speed i so important, then why not use internal fields for 
> write also, if they are so fast to read, they must be fast to 
> write too, no ?

Because in almost the cases, you need to do more than just update the
field, making a write accessor necessary. Read accessors, on the other
hand, almost never do more than return the value as-is.

> Then remove all accesors and all will be good and faster.
> 
> (btw, I don't think the speed difference is so great in a
> normal machine, they are no common path, so a _normal_ app
> using accesors to read properties may be _marginally_ slower
> than using fields directly)

We need benchmarks before drawing conclusions. Often, "marginally slower"
can be used as an excuse for introducing a little more bloat. The bloat
adds up until things are a lot slower than originally.

> >> - Try to avoid to use something like "flag : x;" wich is not 
> >>   supported in other languajes.
> >
> >This should be trivial to parse in and translate into other language
> >equivalents...
> 
> there is no equivalent for this in pascal, believe me.

Sorry, but I don't believe you.

> no, no, no, no, no, please, remove the ": 1",  *please*
> (pascal don't support it, and I'm afraid neither others languajes)

You should map the concept, not how it is implemented in C, onto the
target language. Pascal supports 'boolean' just fine, and that would be
the appropriate mapping of 'guint flag :1'.

> How *I* think is right ? Suppose I'm an object:
> 
> - My fields are _mine_, and I'm the _only_ authorized to 
>   read/write them
>
> - You wana write one of _my_ fields ?
>   Ask me, then if (I want && I can) I'll do for you.
> - You wana know the value of one of _my_ fields ?
>   Ask me, then if (I want && I can) I'll tell you.
> - Don't bother me too much :)

You're ignoring the real world, where computers aren't infinitely fast and
take a noticeable amount of time for function call overhead.

If there were 0 performance penalty & 0 pain to using accessors, I'd be
all for them. Macros are definitely one way to make the first goal within
reach.

More exploration is needed to find out whether accessors will have any
impact on ease of development, etc.

I'm not arguing that the general idea of accessors is bad, just that the
way it is done, and the reasons it is done for, needs consideration.
-- Elliot
"We're sorry, we didn't know it was supposed to be invisible."
	- Sign carried outside US embassy.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]