OOP_(re)

Fri, 30 May 1997 02:50:40 -0400 (EDT)

On Fri, 30 May 1997, Frank Heckenbach wrote:

> 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 was thinking that it would be nice to have this in GPC only because
Delphi had it, without even thinking *how* it could be useful. Now that I
spent some thoughts on this, it's no longer such a good feature to have...
Unnecessary bloat IMHO...

> 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.

Yes, that's what I intend to do for the GPC-specific class library, but
for the BPCOMPAT package, the Load method is a constructor, and we have to
be compatible, so... :-(

> > 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"! :-)

Yes! :-)

> > 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)?

Yes, for now it isn't an interface since the feature isn't there yet! :-)

> > 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)!

Yes, exactly! So I could remove the "Abstract" method (did you receive my
CLASSES.PAS?) from TObject.

> 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).

Quite confident too. Actually, if MI gets in there and creeps into the
generic class libraries that will go with GPC, I'll simply switch
Modula-3.

> > 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.

Actually, it simplify things... (IMHO)

> 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.

Agreed.

> 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).

I thought about that, having a direct TObject descendent (TPersistent),
but the problem lied in abstract classes that has descendents that were
streameable and others that aren't. Like say TCollection, which can be a
collection of streameable objects (where you want to implement TCollection
itself as a streamable class) or not. Do we descend TCollection from
TPersistent or TObject? If we descend from TPersistent, what do we do in
case that the TCollection contains non-streamable objects?

> > 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)").

I like having my objects "cleaned out", but this is really personal... :-)
I guess no constructor is ok if we don't do anything, but I'd like to keep
this... It's easy to bypass if you don't want to use this...

> ...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.

Agreed.

> 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.

Well, for the moment they aren't...

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

Didn't knew that!

Pierre Phaneuf

"The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offense." - Edsger W. Dijkstra.


Pierre Phaneuf (pp@dilu.ml.org)