Quick Modern Object Pascal Introduction, for Programmers

[hnb]

A singleton is not a non-reference counted interface, it is a completely different pattern.
The TSingletonImplementation happens to be one that avoids reference counting but on the wrong assumptions that you could not legally do that
without relying on _AddRef, and _Release. That part is nonsense.

TSingletonImplementation is not my idea, my post is just pure information that we have class which can be used and is sometimes handy. You can find description and comment in Delphi implementation "A non-reference-counted IInterface implementation"... To be clear : calling non-reference counted interface implementation as singleton is IMO bad idea, but that nomenclature exist for a long time in Generics.Default module (which is bad, bad, bad, but it exist - nothing less or more).

I regret that I mentioned TSingletonImplementation .

[michalis]

If you read his examples in his "book" , he actually assigns COM interfaces to object / class variables and then states he doesn't like them.
That's what gets me so angry. He has no clue.

I once again have to start by reminding that the first COM interface example (ref-counted) in my article does not assign interfaces to class variables. So the point you raise was addressed a long time ago. Just check the example in http://michalis.ii.uni.wroc.pl/~michalis/modern_pascal_introduction/modern_pascal_introduction.html#_ugly_com_interfaces and notice how C1, C2 are only used through IMyInterface.

Only the next section "Using COM interfaces with reference-counting disabled" shows the usage through class references. But there we're deadling with non-ref-counted COM interfaces, and your own writeup says "A non-refcounted interfaced object should be instantiated through an object (class) variable.".

And I still don't appreciate your tone -- learn to speak without insulting other people, otherwise it's just difficult to discuss.

Reference counted vs non-reference counted interfaces

The information that you can add reference-counting to CORBA interfaces is interesting, thank you. I will change the article to mention it, to make it clear that all interfaces can be ref-counted, just CORBA is by default not ref-counted.

Still, the CORBA interfaces are easier (and safer -- see below) way of achieving interfaces without ref-counting. The COM / CORBA difference is still not as independent from the ref-counted / non-ref-counted decision, like you suggest. The reason:

On COM interfaces, calling _AddRef and _ReleaseRef is not optional (because IUnknown already declares them). They have to be called always, regardless if _Add/ReleaseRef implementation follow the ref-counting concept or remove it.

So even if you turn off the reference counting for COM interfaces, it is still dangerous to use them through class instances. You need to take special care to never leave any temporary interface variable "hanging" behind when you free the instance. I mentioned it explicitly in the article, with links to http://freepascal.org/docs-html/ref/refse47.html . That's why the section "Using COM interfaces with reference-counting disabled" says it's not advised.

This is different from CORBA interfaces: you can use them through class instances safely (unless you add reference counting, of course). An extra reference to a non-ref-counted CORBA interface doesn't worry you (just like an extra reference to a class instance through a class variable), as long as it's not explicitly dereferenced in code.

So if you want non-ref-counted interfaces, it's easier to go with CORBA, than "COM + special _Add/ReleaseRef implementations". That is my point, and I don't see how your writeup changes anything here.

I will change the article to note that you can make the CORBA with reference counting. The rest of the point still stands: if you want to have interfaces similar to what Java/C# offers, then go with CORBA interfaces (and do not add ref-counting).

[marcov]

The information that you can add reference-counting to CORBA interfaces is interesting, thank you. I will change the article to mention it, to make it clear that all interfaces can be ref-counted, just CORBA is by default not ref-counted.

(actually real Corba interfaces are, just not via unknown, and typically managed manually. The name was always bad, please mention that :-))

Stress that non reference counted interfaces are more "bare" and deemphasize the link to corba and java. Note that iunknown doesn't just do refcounting though, it also plays a part in identity (queryinterface) that allows to get other interfaces supported by the object from the object. (e.g. to see if you can "upcast" an interface to a newer version)

[michalis]

The information that you can add reference-counting to CORBA interfaces is interesting, thank you. I will change the article to mention it, to make it clear that all interfaces can be ref-counted, just CORBA is by default not ref-counted.

(actually real Corba interfaces are, just not via unknown, and typically managed manually. The name was always bad, please mention that :-))

Stress that non reference counted interfaces are more "bare" and deemphasize the link to corba and java. Note that iunknown doesn't just do refcounting though, it also plays a part in identity (queryinterface) that allows to get other interfaces supported by the object from the object. (e.g. to see if you can "upcast" an interface to a newer version)

Roger. The way I understand, the better names would be "always-descend-from-IUnknown" vs "don't-always-descend-from-iUnknown", not "COM" vs "CORBA". That would certainly be clearer for someone who is not interested in interacting with outside services (neither COM nor CORBA) and just wants a language feature (with the purpose of casting two classes to a common interface, because they share a common API, similar to interfaces in Java/C#).

[marcov]

Yes or bare and com/iunknown with com/iunknown inheriting from bare.

[Thaddy]

Ok. This is somewhat going in the right direction....

[kupferstecher]

It's a year now since the TO published his book. It seems to got stuck after the fights about the interface features.

Thats really a pity I think, because such a document can be quite helpful for people new to FPC. So I hope it will get further promoted and also optimised in its content.

Some notes, based on my opinion:
- The title should explicitly contain the words "FPC" and ("syntax" or "language feature"). As this is a document for learning and not an article about modernity.

- The usage of classes should be described better. Especially that the variables of type of a class are only references and the constructor reserves the according memory and the destructor frees it. That classes only work with dynamic memory allocation. For pros this is clear, but its a concept which is not intuitive and a lot of beginners stumble over this.

- The wording 'old style object' is unfortunate. There are use cases where type object is quite useful, also in modern applications. And describing the object 'in range' to the class can help understanding classes.

As said, I hope it goes on~
Regards