According to Frank Heckenbach:
As Pierre said: string comparison are less efficient than integer compares, and generally I think *internal* things (i.e. things that must only be read by computers, not by humans) should use integers rather than strings when there's no real need for strings. Resource files, AFAIK, are binary files, anyway, so what good would it be to have some strings scattered in them?
BO4 has the following `ExecDialog' procedure:
Function ExecDialog ( Index: String; Data: Pointer ): Word;
It gets the dialog from the resource file at index `Index' and lets it work on the data pointed to by `Data'. The return value is the command the user entered to leave the dialog. It's quite similar to TV's ExecDialog, except that you don't pass a pointer to the dialog but an index to the resource file - the object's ID.
A typical call:
Var MyImportantData: record foo, bar: Real; end (* MyImportantData *);
if ExitDialog ( 'EditImportantData', @MyImportantData ) <> cmCancel then UpdateEverything;
Now suppose, the index 'EditImportantData' were an Integer, say 42. Of course, there would be a constant declaration `Const EditImportantData = 42' in some Unit, so the call would be the same but two apostrophies. Okay. But now we introduce more dialogs which are thematically related to the 'EditImportantData' dialog, e.g. 'EditEvenMoreImportantData'. A natural choice for a numeric constant for it would be 43, but that's busy already. So we can either change *all* numerical constants and recompile the whole application or declare `Const EditEvenMoreImportantData = 3742' - whatever is free - which invites for errors when forgetting which numbers represent which dialogs.
[...]
So both IDs could coexist peacefully... :-)
Syntax proposal:
Object(...)[StringID,NumID]
Why not? Looks reasonable ...
(* However I still think it is the job of the library, not the compiler, to provide such IDs. *)
[QueryInterface, etc. ...]
Delphi users: Please help us poor guys to understand how Delphi works, then there is a chance that you can have all these nice features in GPC, too, one day.
In which class, and pointer to which class? Sure, a pointer to TObject could do anything, but would require type casts (which I consider bad style), or absolute declarations (even worse).
Think of a large, well-established library. Now somebody wants to modify for some unexpected situation. Then the programmer (i.e. the user of the library) can either directly add fields whereever appropriate - then communication with other applications which use the same library might become complicated - or use these "hook" fields.
[Example: GCC compiler back-end ...]
Sorry, I don't really feel like wading through 100kB of C code now, but I guess they put in the "unused" fields because they're emulating objects -- for lack of an inheritance mechanism that allows to add fields when they're really needed. So I don't see how this would apply to gpc OOP.
GCC has such extension fields at a number of places: For example, each structure which represents a "type definition" has one "pointer" field pointing to a "struct lang_decl" which must be defined by the language front-end using the GCC back-end. We use this, for example, to store an additional integer in the type definition node which tells whether something is a String, a Schema, an Object, a variant Record, or just an ordinary type - plus some pointers holding Object inheritance information and Schema discriminants.
Of course, this could have been achieved by deriving a successor object, because this happens in the "highest level" of an "object hierarchy": there are no "successor objects" of the "type definition object". But if there were, inheritance would not work any more - this "hook" field still would.
[Implicit type cast with `is' operator ...]
I don't know how difficult this is to implement, but it would be a nice feature. E.g., in a program I have some situations like:
I agree that this would be nice, and I think that this would not be as hard to implement as one would expect on the first guess. (Frank, it's a similar thing as your suggested `iftype' for accessing variable argument lists.)
What does The Standard say about this?
Peter
Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]