Gale Paeper wrote:
Frank Heckenbach wrote:
Adriaan van Os wrote:
Prof A Olowofoyeku (The African Chief) wrote:
What you are describing is almost equal to the "new" style Delphi Classes (actually, this is already over 7 years old, so it is not so new - but I use "new" here to distinguish it from the original BP object model). That type of Delphi compatibility, is, I believe, on the to-do list - but perhaps not a high priority.
There is also the "Object-Oriented Extensions to Pascal" proposal, of the Technical Committee X3J9, see http://www.pascal-central.com/OOE-stds.html.
I have heard that this is quite similar to Delphi's model. (I can only hope that's true, otherwise we might have 4 object models ...)
Although there are quite a few similarities between Delphi and OOE, there are some significant differences which I don't think can be handled in the same object model. For example, Delphi's object model is single inheritance only whereas OOE provides for a limited form of multiple inheritance with the mix-in type property class. Unfortunately, Borland choose to use the property word-symbol for a different feature (which isn't in OOE) so there is a clash in word-symbol useage between the two.
OK, so there are differences, but not necessarily conflicts. The two uses of `property' seem to be in sufficiently different contexts, so they won't conflict. (In the usual way we do things, GPC would then allow both by default and check for the respective dialect options.)
As far a model similarities go, there is a closer similarity between the Mac object mode and OOE's object model than there is between Delphi's and OOE's object models. In many aspects, you could view OOE's object model (and language extensions) as the much improved version 2 of Apple's version 1 Mac Object Pascal which was created in consultation with Wirth in the 1984/85 time period. (If GPC already had the planned for support for OOE, I don't think there would be any need to worry about supporting a separate Mac object model. Although there are a few differences, the differences are relatively minor and could be easily handled with a relatively few conditional compilation directives to handle the object versus class key-word syntax
It may seem minor to you, but in fact this one may be a real conflict (because the same code may mean different things in BP and Mac Pascal).
So obviously we have different metrics. For me, two things having similar or identical syntax and different semantics is quite a bit worse than different syntax and semantics. The latter may be more work to implement it all (but not necessarily), but the former probably means in the end we can only support one or make the result dependent on the dialects. This is always unfortunate (i.e., if the dialect options are not only about whether something is accepted or not, but it's accepted with different meanings; we have such examples, e.g., the `mod' semantics with negative arguments, or the precedence of unary `+' and `-') ...
In passing, I have to mention that I personally prefer the BP object model, see section "E.6.5.1 The Object Model. ... The reference model has the following disadvantages: ...". Still, it is a given fact that traditional Macintosh Pascal compilers implemented the reference model.
To gain a more balanced assessment between the two models, one also needs to see section "D.1 Record Extensions ... The value model has many disadvantages ...".
I tend to disagree:
: + The absence of object identity;
I think this only applies if you allow for object assignments and value parameters. They're part of BP objects indeed, but I find that this object model works well without them. In fact, I haven't implemented them in GPC until a few weeks ago (after the last release), and except maybe for a few rare cases, I don't think anyone has missed them very much. (I haven't needed them in all my code.) In the future, GPC will still warn about them (except in --borland-pascal), so it may be reasonable to talk about the model without copying objects.
: + The absence of complete polymorphism, which is provided only via : pointers and reference parameters;
Which is the normal thing to do (just like, e.g., with Pascal files where it's even required because files must have an identity).
: + An increased dependency between modules; (Modules that have : allocated static records, or that use the size of a record for : allocating storage on the stack, need to be recompiled if the size : of the record changes.)
That's entirely an implementation detail. In GPC, e.g., an importer must be recompiled if a virtual method is inserted/removed/moved. Although this doesn't influence the size of the object, it does change the offsets used internally. Generally, an importer must be recompiled whenever an imported interface changes. (And since usually methods change more often than fields do, I think the disadvantage described above is rather rare/academic.)
: + A more complex model with many nuances involving constructors, : destructors,
I'm not sure if it's really more complex. To me (of course I'm used to it) it seems quite logical, at least more in line with standard Pascal syntax: Dynamic objects are allocated explicitly with `New' and deallocated with `Dispose', just like any other types, and the con-/destructor calls are inserted there. Whereas in the OOE model, constructors are called like functions (although they're declared like procedures, i.e. without result types), and the creation of the object happens somehow "magically" when a new object is created (but not when an inherited constructor is called).
: + A requirement to specify conceptually unnecessary dereferencing;
Unnecessary, depends. Again, I think it's more in line with Pascal's typing in general.
It may be a little easier to use with implicit references, but then the same should probably apply to files (removing the special exceptions that files may only be passed by reference, not returned and assigned).
In summary I think, the OOE model may be a little more practical by itself, but the BP model seems to fit better to Pascal (and that's me, talking about Borland, strange ... ;-).
In hindsight, Wirth might have done a few things differently in Pascal (e.g. files as mentioned, also `endif' maybe). But Pascal being like it is, I doubt whether the OOE model is the best fit for the language ...
This doesn't mean that I'll never implement it, but those problematic differences described above probably also mean extra contortions in the compiler, and therefore more work to implement it, so it not be soon.
As for the implicit object pointer dereferencing, I'm still waiting to decide whether it's useful to do it with pointers to (existing) objects, or if not a distinct object reference type will be necessary anyway (so it wouldn't make much sense to klduge it now with object pointers).
Frank