How would you name TObject’s ancestor class?

By Eric Grange / June 23, 2011

I’m looking for a good name for a “TObject ancestor” class, that would introduce no Pascal baggage: no “Create”, no “Destroy”, no “Free”, etc.
TObject would become a subclass of that root class.

A good name would have to be meaningful as being the “true” root of the class hierarchy, and ideally, it would have to be a name unlikely to conflict with existing class names in existing code (so TRootObject, TBaseObject, etc. likely don’t cut it).

The underlying purpose would be to allow integrating everything in the class system, including objects defined in other languages, and seeing them as objects rather than interfaces (which have a baggage of their own), ie. allow them to have directly accessible fields, allow subclassing, etc.

Any good name ideas?

edit 06-24: Thanks! Quite a lot of comments and suggestions! 😉

To clarify things a bit, the TDWSxxx suggestions are interesting, but semantically-speaking, a TObjet in DWS is an actual DWS object. Also the “ancestor of TObject” would be used to bring in f.i. Java objects, for which TObject methods like .Free or .ClassType f.i. either don’t have a meaning, or would have a different one. One way could be to make all TObject methods virtual and raise exceptions when they’re meaningless, but that would be a runtime solution to what is a compile-time problem.

All this might be a bit fuzzy, as it revolves around things brewing in the lab, and should become clearer in a few weeks time!

FWIW an ancestor of TObject could also be useful in Delphi for special purposes, and could serve as basis for non-reference-counted interfaces (f.i. if you were to introduce a garbage-collection in Delphi).

Related posts

50 thoughts on “How would you name TObject’s ancestor class?”

  1. Here are a few:
    – TSystemObject/SystemObj/SysObj — you get the point
    – TGenericObject/GenObj/etc.
    – TDWSObject/TDWSSysObj — the most appropriate IMHO, since it’s related to DWS…

    Hope it gives some new ideas.

  5. TAbstractObject – but may have conflicts.

    I suspect any relatively simple name is going to have conflicts, somewhere.

  6. Well, that’s a nice challenge. It sounds pretty philosophical since a quest like that involves even thinking what an object is, and in that terms, may be good to apply concepts from that field and others related like metaphysics. So, a “lateral-thinking brainstorm”, without any kind of filter, can output things like:

    TEntity
    TSubstance
    TEssence
    TInstance
    TBeing
    TCause
    TUniversal
    TParticular

    Oh, if you ask me to pick one from those, I might select TEntity.

    Another way to see the problem, from the input side, is not looking around the subject (“object” in this case) but around the implied modifier (“root”), and that can involve looking for a synonym:

    TRoot
    TOrigin
    TMaster
    TBase

    I should pick TRoot from that list.

    Finally, yet another way to think the whole thing is from the point of view of the output, and what is expected in this case is a pascal type name, which by convention starts with T but it might not. So, other posibilities might be “Object” or “TT”, discarding “T” due to the generics usage.

  11. Maybe “TType” if all types were to descend from it, or “TClassType” if it’s only the base of all classes.

    type
    TType = type()
    end;

    TStringType = type(TType)
    end;

    TClassType = type(TType)
    //somehow defines “class” keyword
    end;

    TRecordType = type(TType)
    //somehow defines “record” keyword
    end;

    TObject = class(TClassType)
    end;

    I do think it’s unsafe having .Free() allowed on every object, as you can call Button1.Font.Free() for example, whereas Delphi shouldn’t allow that on objects that are meant to be completely managed by another object. However, how do you intend to allow these objects to be freed, and what about when you want the exact same class that does have Free/Create/Destroy.

  14. T_ is a valid name, won’t produce naming conflict, will indicate it is a type, and is abstract enough not to be used by anyone (only if knowning compiler intrinsics).

  16. What about Latin?

    TPrimo; primo: first, at first, at the beginning, at the start
    TPrimoris; primoris: first, foremost/most distinguished, first

    or get different ideas with an English-Latin dictionary.

  24. Well I can brainstorm names for a new supertype a few :

    TSuperType
    TMom
    T_MrT
    TBoson
    TBigBang
    Tcore
    TMore
    TParticle
    TElementory
    TToo
    TMaster

  27. If this base class was the superclass of TObject, how would you, or would you do, the following?

    1. Unify value types (Integer, also RECORD)and inherently-by-reference-to-memory-on-heap (TObject) types? If you do, you end up with a set of really odd problems, especially since the entire point of a record, instead of a class, is that Delphi class types that descend from TObject are inherently always by reference.

    2. Create/Destroy are inherent in by-reference, and are part of the semantics of TObject being always on the heap. So if TBaseObject (if we call it that) is by value, and thus Integer could also inherit from it, we would have to permit “messages” or “methods” to be called on those integer objects. How do you propose to handle methods or messages on integers?

    It almost sounds like you’ve got “Let’s implement Smalltalk as it would have been invented by Niklaus Wirth”, in mind.

    Warren

  37. I can’t believe it took so long for someone to suggest T42.

    On the other hand, I can perfectly understand why no-one has yet suggested:

    TK421
    or THX1138

    🙂

    Or drawing upon Tolkien (I am supposing that this type is unlikely to be ever/rarely directly referenced, so a symbolic name can be purely that – symbolic and could be entirely arbitrary, so embedding some poetry/soul in it wouldn’t interfere with practicalities too much):

    TEa (Ea: The World that is)
    TIluvatar (Illuvatar: The Father of All)

  38. I would probably name it just “T” 🙂

    But anyway, I don’t think this a good idea at all. TObject is a /the/ base class and not just since a few months. It’s basically safe to assume that every object is at at least a TObject. Introducing something above TObject would break this “safe” assumption.

  39. You could go the route of the naming conventions of the various Components…TEdit, for example.

    So, TCustomObject becomes the new base class, with TObject the Delphi implementation of TCustomObject. TThisObject is some alternative implementation, TThatObject another implementation, etc. etc.

    You’d gain the benefit of adopting an existing meme which matches the nature of the relationship you’re expressing, and as far as I know, there are no collisions (at least within the stock code).

    J.

  40. a funny name TJinx :p

    now seriously here are a few more:

    TDWSSuper/TSuper
    T_ — as Arnaud Bouchez mentioned would be a good one also
    __MetaObj[ect]__ — not sure about this one… might be OK
    __[T]Object__ — the two underscores before and after should be sufficient for name conflict

Comments are closed.