Re: What's OOP?

På Mon, 25 Apr 2005 20:32:34 +0200, skrev wolfgang kern <nowhere@xxxxxxxxxxx>:


Last measure displayed just 40 mV across my ears when in bright sunlight.
Even if I tried to connect a female there, it's just DC, so the sunlight
effect may not fully do the job.


:) To advanced joke for me.


And now ask me what this got to do with OOP... OnlyOralPower?

Hmm. I dont care to discuss it. If I tell anyone what oop really is they will come after me saying I dont know ***.

But between you and me.

oop, stands for object origented programming. The "object" word was invented to distinguish from a record, for purposes of propaganda, coolness, and so on and so forth. Anyway, an object, is usually a thing, irl, so just anything could be an object, so the name is imo well chosen. Record is also a strange name. But we're just gotten used to it. We could also call a record a chunk of bytes. Or the description of a chunk of bytes.

We usually do not call a chunk of bytes, a record, unless there are more then one of them. But a record is really a description of a collection of bytes, and nothing else.

Maybe you could say that the record is really only the description, the format spesification of the chunk of bytes. And then a Class is the same to an object. The class is the description of the object.

In addition to the record field, an object can also have "Methods". A Method is the same as a subroutine. The method is designed to work on its record only (mostly, mainly), and usually a register is reserved to carry a pointer to the record, when the method executes.

Most methods are Static. That is, they are called "directly" Others are virtual, and that means that the target address of the call is linked at runtime. This is the same basically as using a jumptable.
Each class description is carrying a VMT (Virtual Method Table) and this table is identical / Shared between objects having the same class, but diffrent between objects of diffrent class. This is why a method can be "virtual". The target address of a virtual call, depends on the class making the call. Or in other words, on the content of the "objectregister". But for two classes in the same object three, the final destination, could be the same, or it could be diffrent. this depends if the jump table has been changed in the inheritance process. (Overriden)

Again the object is a collection of bytes. We simplify by looking at the collection of bytes as one thing. An Object.

When a class inherit another class, this is the same as merging their two records. So the new class, is put toogether from the class description of two classes. In reality what this means is that the records fields merge. Also they inherit the WMT of the "parent" object. e.g, their method tabels merge as well.

Usually the pointers are stored at negative offsets in the very same record as is the object, for instance (not accurate) :
_______________________
MethodPtr2 - 12 ( When an object is created,
MethodPtr1 - 8 a chunk of memory is allocated from the heap,
Classpointer - 4 and the negative offsets are initialized
Field1 - 0 by the RTL, and then the
Filed2 4 positive offsets are NULLED out ).
Field3 8
__________________________

In this way the new object can make use of all the functionality on the parent object, just as if the parent was a small library. By calling its subroutines. It can also change / extend the functionality, it can replace functionality or destroy / disable functionality.

In modern HLLs like Delphi and C++ etc, oop also have more rules. But in my GUI, I do not use any of theese other rules. I use the above, which is the most benefitial part of oop, imo. Except that I organize the objects in a much simpler way.

The other parts of oop, like information hiding, field protection, interfaces, field access spesifiers, I dont use those. In any part of the three I am accessing the fields directly.

OOP is thought of as a tree stucture. But it really is not. It only looks that way. In any decendant, anywhere, it is allways the exaxt same, a record + and methods.

There are absolutly no reasons why the small part of OOP i use, which for the most part is just for the thinking purpose, and the organizational purpose, should slow things down, in respect to "flat" code, because in reality what I do is to flatten out oop. Instead of having rigid rules, I follow them, without having the limitation to not be able to break them.

For the OOP as part of an assembly syntax this seems to me unwanted, and uneeded. Not to say that it couldnt work. My take on this is that any assmebly code, is nothing but a symbolic representation of the machine/hex codes. And ANY *GOOD* symbols will do.

I dont really think that having OOP syntax in an assembler would make it easier. If someone are going to change the symbol representation at this point, they should think long and hard before doing it, and the new symbols should offer clear advantages.

I would rather have :

Exchange eax ebx

then

eax.xchg(ebx)

or

Increment eax

rather then eax.Inc

In fact, all this talk about assemblers and listening to Beth, have made me, now and then, wonder if I am sooner or later going to build an assembler. But this assembler will be nothing like any of you guys would ever consider. Maybe Betov, but I dont think even him, as I would have made it a 100 visual assembler. And I dont mean visual as in visual or or having forms and such. I mean something complety diffrent, so diffrent that I dont want to mention it, as you will surly just laugh.




__
wolfgang 

.