Peter Gerwinski wrote:
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.
As I said, IDs must be chosen with a little more sophisticated mechanism.
Since nobody told us anything about these Delphi/Windoze things, I'm just suggesting something. Let's say the ID is a 64 bit integer (if Delphi has 128 bit, that might be more compatible, but I don't know...). So let's say 32 of these 64 bits are a unique programmer ID. The other 32 bits can be used by the programmer as (s)he chooses. So you could use 16 bits as a unique unit ID (I guess you won't write more than 65536 units in your life), and 16 bits as a unique ID per unit (max. 65536 classes per unit). No renumbering necessary ever, even if you included someone else's sources! :-)
So you could declare:
const JHackerID=$E94F561A00000000; {Your ID, declared once, globally}
const JEditorID=JHackerID+$12000000; {For each project}
const EditUnitID=JEditorID+$240000; {For each unit}
const EditCommandsID=ThisUnitID+$1000; {For each "kind" of IDs}
const EditImportantData=EditCommandsID+42;
You may or may not need either or all of project or unit level or "kinds" of IDs, that's any programmer's own choice.
Object(...)[StringID,NumID]
Why not? Looks reasonable ...
Fine! :-) Then we've only got to decide about the size of the NumID. I think 64 or 128 bits are reasonable, but which?
(* However I still think it is the job of the library, not the compiler, to provide such IDs. *)
But typing "const ClassName:^String value @'EditImportantData';" is not very convenient, is it? (Apart from the fact that the syntax "@'...'" doesn't work, does it? So it would be even more complicated to declare, or one would have to use a CString.) Besides, a check for duplicate NumIDs could only be done at runtime. :-(
So the compiler could help a little. Since it's only optional (it will not be linked in if not used), I see no disadvantage.
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.
Yes, please!
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.
I don't understand. Adding fields without code that accesses the new fields doesn't do anything. So if you add the new fields, you'll also have to provide new methods, won't you? So you'll have to derive new classes with the new methods, and those classes get the new fields. That's what one would do normally.
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.
What kind of successors? AFAICS, these different types (Strings, Schemata, Object, variant Record, ...) *are* the natural descendants of the abstract type "TType".
Can you give me an example of another "orthogonal" inheritance? If it is specific only to one language, this language would declare an abstract successor of "TType" with the "hook", which would probably be more specific than just "PObject" then. Other languages wouldn't have the hook.
That's one of the main ideas behind OOP: not having to provide "holes" for any unknown future extensions, but being able to add what's needed when it's needed.
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.)
I know, but AFAIR there wasn't much response to this suggestion. But with objects it seems easier to do than with normal types.
What does The Standard say about this?
Actually, which standard? Do you mean Object Pascal? How much does gpc comply to this standard at all? (Up to now, we've only oriented on BP and some ideas of our own, haven't we?)