David Fiddes wrote:

From: Frank Heckenbach heckenb@mi.uni-erlangen.de

<snip> >Would an ID of 8 bytes matter, i.e. are there any stream files where >4 additional bytes per object would matter? <snip>

Why not make them 16 bytes? Sounds excessive maybe but that's how big a Globally Unique IDentifier (GUID)(or more pretensiously a Universally Unique IDentifier (UUID)) is...128bits....and there's a stanard for generating them...and anyone with a windows machine has an implementation of that(and the Mac and some UNIX boxes too). Upwardly comaptible with Microsofts Component Object Model(COM) and I'm sure the likes of CORBA use them too...

Is this a standard set by M$? If so, I'd only vote for using it, if it (unlike most M$ "standards") - was openly documented, - was not subject to change at M$'s decision, and - can be used for purposes like ours without possibly conflicting with other (future) uses

If this is so, I'd like to know more about these IDs.

The African Chief wrote:

...

BTW: Would it be possible at all? Doesn't TObject refer to TStream?

No, it doesn't. In bpcompat, TObject has a "Load" constructor that takes a TObject parameter.

But doesn't it have to refer to the stream somehow? Do you type-cast the parameter into a stream (which I wouldn't like, since IMHO type-casting should be avoided wherever possible - it's the "goto" of data structures), or did you implement some of a stream's properties within TObject (which I also don't like, see the discussion about handles)? Sorry for asking, but I don't have bpcompat at hand, and I can't imagine another way...

...

I don't know all the details here, but isn't it possible to have a TWindow(TObject) with Handle being a field of TWindow, and this function returning a PWindow? This would seem natural to me.

Yes, that is possible. But I don't think it does any harm to have the Handle in TObject instead.

Perhaps not (besides wasting 4 bytes...), but I only know from my own experience that I did sometimes regret thoughts like that. Therefore, I'd prefer to think about classes very exactly, especially about such base classes. And again, what's the disadvantage of putting Handle into another class?

Perhaps. But there are many times when I have wished that certain things existed in BP's TObject and TWindowsObject. Making a descendant object is fair enough, but it would have been a lot easier for me if the things were in the ancestor.

Easier perhaps, at least at first sight. But when many people use a class library and change it like that, things can get very complicated soon. It is a bit more work to create a more detailed class hierarchy and to introduce all the fields at the "right" place, but I think in the long run, it's worth the effort - and it's more in the spirit of OOP, as I understand it.

...

I'm probably missing something - but isn't the address of an object a "unique ID"? (One that makes it very easy to "locate" the object... ;-)

As I said, I might be missing something, but I still don't know what it is...

That assumes that you already know the object and its address.

If you used the address everywhere you use the ID now, you would know, wouldn't you?

If you already know it, there would be no point trying to locate it again.

That's what I meant by "very easy to locate"...

Also, there are a whole load of things that you can do with integers that you cannot do with addresses.

Yes, but what do you need to do with IDs? AFAICS, one only needs to compare them (for equality, not for greater/less), and this can be done with addresses.

And, suppose that, for some obscure reason, I suddenly wanted to locate all currently active object instances and/or their parents (if any), how would I do this using addresses? - but I could do this with a loop through the SelfIDs.

Where do you get the SelfIDs from? Perhaps a list of IDs stored in a parent object? You could put the addresses there instead, couldn't you?

I'm really trying to understand what you do with these IDs!

I hope, it's not only the (bad, IMHO) tendency of Windoze to use "untyped" handles for each and everything - that might not matter much in C (where everything is int anway - well almost...), but I think in Pascal we should try to keep as much typed information (e.g. typed pointers) as possible.

Pierre Phaneuf wrote:

...

Then it would have to be in the GPI file. Much effort. I think the few bytes we can save like that (Just those for the strings plus one pointer in each VMT) are not worth it, but perhaps somebody else wants to try himself on this problem? ;-)

This is totally optional to me, and thinking more about it, I was wondering of what use having the symbol name of an object at runtime...

I'm also wondering! I never used Delphi, so I don't know what use it has there. But from my experience, I don't know any case where this is needed - except debugging, of course, but that's another story.

I think, if some program for any reason does need this information, it could declare object constants (if implemented), or methods (in the meantime) that provide this information explicitly, but unless there's a wide need for this information (which I can't see), I don't think it should be included automatically.

...

(* I suggest to define a pointer to a procedure like the constructor *)
(* with an *explicit* `Self' parameter, to cast `LoadPtr' to it and  *)
(* then call it.                                                     *)

Its the explicit part I'm trying to avoid... I guess this part will be compiler dependent, but should be among very few (with the TObject.Init constructor).

I agree. Also, I don't like the type-casting bit. But, AFAICS, making Load a virtual method (or virtual constructor in the future?) would remove all these problems. Since the VMT has been assigned at this point, a virtual method can be called without any tricks.

Also note that Java has been widely recognized as "C++ as it should have been" (by Bjarne Stroustrup among others, the designer of C++), and Java *doesn't* have multiple inheritance.

:-)

So, let's make "BP objects as they should have been"! :-)

For instance, I tried to make my class as much object-oriented as possible, free of any procedures. For example, Abstract has been made a method of TObject and a similar NoStream method has been added to prevent streaming of non-streamable objects (this is very quite not final, susceptible to removal).

Perhaps "streamability" would be a good choice for an interface (with the methods load and store)?

A thing that would be better to have than multiple inheritance would be pure virtual methods. Would allow me to remove that Abstract method! ;-)

I assume "pure virtual" is the same as "abstract" methods!? I.e., any class that has at least one abstract method can't be instantiated.

This would indeed be a much better way than Borland's "abtract method" that causes a runtime error (again, IMHO, a failure by Borland)!

The African Chief wrote:

No. C++ is clumsy and bloated. However, the problem is that MI is part of the language definition. If it were to be implemented in GPC, it wouldn't be part of any definition. It would just be a local extension that could be ignored by anybody who so wishes. I don't see that having such an extension is so bad. Some day, someone will want to use it, and it doesn't help to tell them that they don't need it.

Since interfaces are probably easier to implement (see my other mail), and sufficient for most cases (including all that I know), I suggest implementing interfaces first. If then there is a need for MI that really can't be solved with interfaces, it's time to think about adding MI (but actually I'm quite confident this won't be the case).

A purely personal thing, perhaps. If I did it my own way, without any preconceived notions, I would have an ancestor object which would contain everything that I think every object should have.

Right, everything that *every* object should have, not everything that *some* objects should have. E.g. handles: not every object has a handle, so it should not be in the base class. If in a windowing system, every instance of TWindow and its childs will have a handle, then Handle should be a field of TWindow.

I know that this complicates matters, especially in the base classes, but since this is mostly a one-time job, I think it's worth the effort.

What I think every object should have changes from time to time, and therefore, for me, it is better to start with more, than with less ;-)

As I said above, if many people with different opinions worked on such a class library, it would always be changing. AFAIK, the purpose of OOP is to have some base classes that can be used by everybody, and more special classes built on top of them that implement the needs of different applications.

...

I really don't see what a TWindow object and a TString object has in common that should be in TObject!

They could all have a Name, a SelfID, a Parent, and a Child.

Do you mean a name/ID/parent/child of the *class*, or of the *instance*? In the former case, I agree (except for the name, which IMHO usually isn't needed at runtime, see above), in the latter case I don't: a string doesn't have a parent or a child or a name (besides the compile-time identifier), and I don't think it usually needs an ID.

...

BP didn't set that trend BTW. The Smalltalk anscestor object doesn't do *ANYTHING*.

The first thing I would do to it is to change that omission ;)

Why not simply derive one (or several) classes from it with whatever you want? That would be in the spirit of OOP (not to change existing classes, but just derive new ones from them).

And what is the point of have the ancestor then - just for type compatibility ?

Yes - to do things in a typed way that need "Void" or "untyped parameters" otherwise.

So it should have only properties that really *every* object has - which, of course, can't be many, merely administrative things like a VMT pointer, perhaps an empty constructor and destructor, and properties of the class like parent class, (perhaps) child classes, (perhaps) implemented interfaces, (perhaps) ID.

Anything more (e.g. load and store methods) will not be common to all objects (e.g. a mouse object probably can't be stored in a stream), so this should be introduced in another class (or interface).

...

BPs constructor fills the object with zeros for instance. :-)

Not very useful at all. They might as well not have any constructor or destructor.

Agreed. Since TObject is an abstract class, it really doesn't need a constructor. The destructor is ok, since it's virtual, therefore must be declared at the base class (this allows removing any object with "Dispose(...,Done)").

Peter Gerwinski wrote:

I suggest to forget about the switch and just store a pointer to a string constant holding the name of the object in the VMT. Since we don't need to care about a 64k data segment (4GB will be enough for a while), these few extra bytes are harmless.

...if there's a real need for it. Otherwise I think, compile-time information like identfiers does not belong in the executable (apart from debug info). I think some people wouldn't like their identifiers to be revealed in a program that's distributed without source.

...

[...] In general, I'm against "magic" things, like the New() function, or the Write()/WriteLn() functions (in BP at least, they cannot be implemented using the language!).

So am I. That's one beauty of C: Everything, including `printf' and such, is user-definable. (Said by someone who is hacking a Pascal compiler because he cannot stand the ugly syntax of C/C++ ... ;-)

Many "un-definable" Pascal procedures could be defined with overloading and/or optional parameters. Both is possible to do in Pascal, and I hope, gpc will have them sometime.

New and Write (and so on) are (basically) a syntactical simplification for calling procedures that could have been implemented in Pascal. And this is NOT user-definable in C, it's simply missing there! Printf requires the user to explicitly state all the types, while Write does this automatically, and "p=(*t)malloc(sizeof(t))" is not quite the same as "new(p)".

Oh, BTW: "sizeof" is not user-definable in C - so they just made it an operator instead of a function, what a difference! ;-)

So don't admire C too much for this... ;-)