Menu
▾
▴
firebird-devel
|
From: Adriano d. S. F. <adr...@gm...> - 2011-03-30 20:18:34
|
On 30-03-2011 17:09, Vlad Khorsun wrote: >>> Therefore it will be very desirable to add queryInterface to the our base interface, >>> even empty or raising notImplemented error. IUnknown *is* industry standard, despite >>> of our wish to accept it. >>> >>> Simple Delphi wrappers could be written to deal with reference counters but >>> i prefer to add queryInterface to the our interfaces. >>> >> No, it's not desirable to add bogus method to our interface. > > Make it not bogus > Then go months ago and re-discuss the versioning approach. >> We also use >> different calling convention than COM, otherwise our versioning system >> don't work. > > Here i don't understand you. Also, please, don't use wors "COM" everywhere, this just > wrong and annoying. > Delphi IInterface is documented to be same as IUnknown under Windows. And IUnknown is for COM. So this interface declare methods using stdcall. stdcall is incompatible with our approach to upgradeInterface. Sure two methods may use it, but I see no reason to have all these mix and bogus (queryInterface) to please a very small fraction of Delphi users while, ... > There is no stack allocated objects, yes. But if you ask google, you'll find a samples of > how to use interfaces to implement RAII. It is not as natural as in C++, but it is exists. ... there are ways to use it without we need *such* a hack of bogus queryInterface, and ... > > We have contacts with vendors of most used component libraries. It is more than enough > to have support of new API from them. Moreover, it will be not too hard to create Delphi unit > with necessary declarations (and wrappers, if needed) to me. > ... everybody is going to wrap it on another thing best suited for Delphi. Adriano |
|
From: Vlad K. <hv...@us...> - 2011-03-30 21:35:30
|
> stdcall is incompatible with our approach to upgradeInterface.
Why ? I see no reason for it.
Regards,
Vlad
|
|
From: Adriano d. S. F. <adr...@gm...> - 2011-03-30 22:07:24
|
On 30-03-2011 18:35, Vlad Khorsun wrote: >> stdcall is incompatible with our approach to upgradeInterface. > > Why ? I see no reason for it. > We add methods to vtable, which expect single "status" parameter, but user may call this methods with many parameters. Only cdecl would handle this. Adriano |
|
From: Alex P. <pes...@ma...> - 2011-03-31 09:41:48
|
On 03/31/11 02:07, Adriano dos Santos Fernandes wrote: > On 30-03-2011 18:35, Vlad Khorsun wrote: >>> stdcall is incompatible with our approach to upgradeInterface. >> Why ? I see no reason for it. >> > We add methods to vtable, which expect single "status" parameter, but > user may call this methods with many parameters. Only cdecl would handle > this. To be precise - added functions may have no parameters at all, nothing prevents them to throw exception instead of filling status vector. This is a choice of one who is calling upgradeInterface(). And certainly yes - only cdecl calling convention may be used here. |
|
From: Alex P. <pes...@ma...> - 2011-03-31 09:46:55
|
On 03/31/11 00:18, Adriano dos Santos Fernandes wrote: > On 30-03-2011 17:09, Vlad Khorsun wrote: >>>> Therefore it will be very desirable to add queryInterface to the our base interface, >>>> even empty or raising notImplemented error. IUnknown *is* industry standard, despite >>>> of our wish to accept it. >>>> >>>> Simple Delphi wrappers could be written to deal with reference counters but >>>> i prefer to add queryInterface to the our interfaces. >>>> >>> No, it's not desirable to add bogus method to our interface. >> Make it not bogus >> > Then go months ago and re-discuss the versioning approach. I do not see why presence of queryInterface() is incompatible with our version upgrade mechanism. Therefore if really need so much to have binary compatibility with IUnknown - we can add it. |
|
From: Kovalenko D. <dmi...@gm...> - 2011-03-30 11:15:35
|
> Ok, here is a code: > > Interface* a = new RefCountedClass; > Interface* b = NULL; > b = a; > delete a; > b->Anything(); > > I don't understand how reference counting works here. Could you explain? InterfacePtr a(new RefCountedClass()); //cntRef==1 InterfacePtr b; a=b; //cntRef==2 a.Release(); //or a=NULL; //cntRef==1 b->Anything(); b.Release(); //last release b.Release(); //no problem --- When you work with RefCountedClass, you must forget about "operator delete" In good C++ code, you do not make a explicit call of AddRef/Release. This is work for smart-pointer Regards, Kovalenko Dmitry |
|
From: Adriano d. S. F. <adr...@gm...> - 2011-03-30 14:39:57
|
On 30-03-2011 07:32, Vlad Khorsun wrote: >> 30.03.2011 11:56, Alex Peshkoff wrote: >>> Dmitry, please do not mix artificially created pointers (BTW, why so >>> complex example with 123456? 0 will cause crash too.) with pointers, >>> that were correct, but were destroyed in another thread. Your sample >>> shows an error in the program. On the other hand, access to a pointer >>> that was correct, but became invalid, is rather typical case when >>> dealing with MT program. >> >> There is no difference. Whether pointer was invalid from the beginning or become, >> result is the same. > > Your example is a crash in *user* code, not in ours. > >> AFAIU, you want to protect API latter with reference counter, but it >> will work only in correctly written programs. But such programs work correctly without >> reference counters. So, what's the point? > > > Reference counting prevents MT races in most cases, it is already used by our code > internally and allows user to not add additional locking layer for MT safety. > >>> Dmitry Kovalenko watched 'invalid >>> handle value' error in his IB provider. What else arguments do you need >>> to let people use API with protected from disappearance pointers? >> >> I'd like to be sure that such protection will have any advantage over current abstract >> handles. So far I don't see in proposals any difference from current design, so I don't >> understand the purpose of changes. > > > Handles always checked before dereferencing. It have its cost both in memory usage and > CPU instructions. > > Interface pointers needs no implicit checks by our code because it will crash in user code > when VMT is accessed. > > Do you see the difference ? > If user pass an invalid pointer parameter, it *will* crash in our code: provider->attachDatabase((Status*) 0x1, (char*) 0x1, ...); We can't prevent wrong program from crashing in our code. The same is about: freedObject->something(); Adriano |
|
From: Alex P. <pes...@ma...> - 2011-03-31 10:06:23
|
On 03/30/11 18:39, Adriano dos Santos Fernandes wrote: >> Do you see the difference ? >> > If user pass an invalid pointer parameter, it *will* crash in our code: > > provider->attachDatabase((Status*) 0x1, (char*) 0x1, ...); > > We can't prevent wrong program from crashing in our code. The same is about: > > freedObject->something(); Adriano, without reference counts we really can't prevent crash with freedObject. And one of main reasons for reference counters to exist - prevent such crashes. |
|
From: Adriano d. S. F. <adr...@gm...> - 2011-03-29 15:00:22
|
On 29-03-2011 10:45, Alex Peshkoff wrote: > We have too many problems in single thread. I try to divide it to > smaller parts. > The first one - here we at least all seem to talk about same thing:-) - > is to use reference counters or not. > > On 03/28/11 22:45, Adriano dos Santos Fernandes wrote: >> User should *not* request a detachment and then request actions on the >> objects. This *is* user application problem, no mater it being single or >> multi thread. > > In that case our new API is regression compared with old ISC API with > handles. Pre FB3 an attempt to request actions on the objects after > detachment cause correct reply from client library - invalid handle. > Without reference count support we will get segfault in FB3. I treat > this as serious regression. > You're trying to make two different worlds to look similar. Take another look at it. Thread 1 detachs and makes it handle invalid. Thread 2 allocs 0xFFFFFFFF handles. Thread 3 is scheduled to run and use the old invalid, but now valid handle. Very pessimistic and "impossible" to happen, but shows that application doing this with handles are still incorrect. You also didn't replied yet to me what will happen when you detach a parent without free children: leaks or will regret your refcounters? In anyway, it shows you're using an incorrect solution. > As one of users replied: Object-based interfaces should use the refcount. Against him is almost entire world who built API without refcount. Adriano |
|
From: Alex P. <pes...@ma...> - 2011-03-30 10:24:06
|
On 03/29/11 18:58, Adriano dos Santos Fernandes wrote: > On 29-03-2011 10:45, Alex Peshkoff wrote: >> We have too many problems in single thread. I try to divide it to >> smaller parts. >> The first one - here we at least all seem to talk about same thing:-) - >> is to use reference counters or not. >> >> On 03/28/11 22:45, Adriano dos Santos Fernandes wrote: >>> User should *not* request a detachment and then request actions on the >>> objects. This *is* user application problem, no mater it being single or >>> multi thread. >> In that case our new API is regression compared with old ISC API with >> handles. Pre FB3 an attempt to request actions on the objects after >> detachment cause correct reply from client library - invalid handle. >> Without reference count support we will get segfault in FB3. I treat >> this as serious regression. >> > You're trying to make two different worlds to look similar. > > Take another look at it. > > Thread 1 detachs and makes it handle invalid. > > Thread 2 allocs 0xFFFFFFFF handles. > > Thread 3 is scheduled to run and use the old invalid, but now valid handle. > > Very pessimistic and "impossible" to happen, but shows that application > doing this with handles are still incorrect. As you understand yourself, this is not realistic example. Cases when thread 3 is trying to work with old invalid handle and gets appropriate error message is reality. > You also didn't replied yet to me what will happen when you detach a > parent without free children: leaks or will regret your refcounters? Sorry, may be I've missed that question. The answer is simple - objects will exist until refcounters > 0, but will be marked in a way, making them return 'object is invalid' error for any request. > In anyway, it shows you're using an incorrect solution. > This words are absolutely unrelated with what you've asked before... >> As one of users replied: Object-based interfaces should use the refcount. > Against him is almost entire world who built API without refcount. All the world is ambiguous here. See for example http://api.openoffice.org/docs/common/ref/com/sun/star/uno/XInterface.html BTW, all people who care about thread safety build object-oriented API with reference counters. |
|
From: Adriano d. S. F. <adr...@gm...> - 2011-03-30 14:44:46
|
On 30-03-2011 07:23, Alex Peshkoff wrote: > On 03/29/11 18:58, Adriano dos Santos Fernandes wrote: >> On 29-03-2011 10:45, Alex Peshkoff wrote: >>> We have too many problems in single thread. I try to divide it to >>> smaller parts. >>> The first one - here we at least all seem to talk about same thing:-) - >>> is to use reference counters or not. >>> >>> On 03/28/11 22:45, Adriano dos Santos Fernandes wrote: >>>> User should *not* request a detachment and then request actions on the >>>> objects. This *is* user application problem, no mater it being single or >>>> multi thread. >>> In that case our new API is regression compared with old ISC API with >>> handles. Pre FB3 an attempt to request actions on the objects after >>> detachment cause correct reply from client library - invalid handle. >>> Without reference count support we will get segfault in FB3. I treat >>> this as serious regression. >>> >> You're trying to make two different worlds to look similar. >> >> Take another look at it. >> >> Thread 1 detachs and makes it handle invalid. >> >> Thread 2 allocs 0xFFFFFFFF handles. >> >> Thread 3 is scheduled to run and use the old invalid, but now valid handle. >> >> Very pessimistic and "impossible" to happen, but shows that application >> doing this with handles are still incorrect. > > As you understand yourself, this is not realistic example. > Cases when thread 3 is trying to work with old invalid handle and gets > appropriate error message is reality. >> You also didn't replied yet to me what will happen when you detach a >> parent without free children: leaks or will regret your refcounters? > > Sorry, may be I've missed that question. > The answer is simple - objects will exist until refcounters > 0, but > will be marked in a way, making them return 'object is invalid' error > for any request. > And not everyone is using C++ and RAII. This will create a lot of leaks. People would like to detach a parent and not care about statements created but unfreed for this attachment. And for who is using C++ and RAII, they don't need addRef/release in our objects to use that. > >>> As one of users replied: Object-based interfaces should use the refcount. >> Against him is almost entire world who built API without refcount. > > All the world is ambiguous here. See for example > http://api.openoffice.org/docs/common/ref/com/sun/star/uno/XInterface.html > BTW, all people who care about thread safety build object-oriented API > with reference counters. > Well, if you want to say that someone is correct just because chose the COM way, then we would need to say we're incorrect because we don't use queryInterface... Adriano |
|
From: Alex P. <pes...@ma...> - 2011-03-31 10:50:05
|
On 03/30/11 18:44, Adriano dos Santos Fernandes wrote: > On 30-03-2011 07:23, Alex Peshkoff wrote: >> On 03/29/11 18:58, Adriano dos Santos Fernandes wrote: >>> On 29-03-2011 10:45, Alex Peshkoff wrote: >>>> We have too many problems in single thread. I try to divide it to >>>> smaller parts. >>>> The first one - here we at least all seem to talk about same thing:-) - >>>> is to use reference counters or not. >>>> >>>> On 03/28/11 22:45, Adriano dos Santos Fernandes wrote: >>>>> User should *not* request a detachment and then request actions on the >>>>> objects. This *is* user application problem, no mater it being single or >>>>> multi thread. >>>> In that case our new API is regression compared with old ISC API with >>>> handles. Pre FB3 an attempt to request actions on the objects after >>>> detachment cause correct reply from client library - invalid handle. >>>> Without reference count support we will get segfault in FB3. I treat >>>> this as serious regression. >>>> >>> You're trying to make two different worlds to look similar. >>> >>> Take another look at it. >>> >>> Thread 1 detachs and makes it handle invalid. >>> >>> Thread 2 allocs 0xFFFFFFFF handles. >>> >>> Thread 3 is scheduled to run and use the old invalid, but now valid handle. >>> >>> Very pessimistic and "impossible" to happen, but shows that application >>> doing this with handles are still incorrect. >> As you understand yourself, this is not realistic example. >> Cases when thread 3 is trying to work with old invalid handle and gets >> appropriate error message is reality. >>> You also didn't replied yet to me what will happen when you detach a >>> parent without free children: leaks or will regret your refcounters? >> Sorry, may be I've missed that question. >> The answer is simple - objects will exist until refcounters > 0, but >> will be marked in a way, making them return 'object is invalid' error >> for any request. >> > And not everyone is using C++ and RAII. This will create a lot of leaks. You've forgotten that such people are not forced to use addRef/release at all. > People would like to detach a parent and not care about statements > created but unfreed for this attachment. > If they do not call addRef for statements, they will be destroyed when attachment goes away > And for who is using C++ and RAII, they don't need addRef/release in our > objects to use that. Absolutely wrong. > Well, if you want to say that someone is correct just because chose the > COM way, then we would need to say we're incorrect because we don't use > queryInterface... In many aspects use of queryInterface might be ideal. Two main reasons why we can't use it: - it will cause additional delays in time-critical places like fetching next record, - it will pollute each place in the code where we work with plugins. On the other hand I see no problems with adding that method to our interfaces, specially if it's needed to make Delphi people life easier. It does not conflict with our versioning support. |
|
From: Kjell R. <kje...@da...> - 2011-03-31 11:00:58
Attachments:
kjell_rilbe.vcf
|
Alex Peshkoff skriver: > In many aspects use of queryInterface might be ideal. Two main reasons > why we can't use it: > - it will cause additional delays in time-critical places like fetching > next record, > - it will pollute each place in the code where we work with plugins. > > On the other hand I see no problems with adding that method to our > interfaces, specially if it's needed to make Delphi people life easier. > It does not conflict with our versioning support. Generally speaking, I feel it's completely wrong to add something to an api only because some clients/users would expect it, unless it actually does something useful in the api. it will only lead to extra complexity and problems down the line. So, if the only reason to add queryInterface is to make Delphi users' life easier I'd say no, even if I've been a huge Delphi fan ever since version 1. (Left it for VS, .Net and C# now though). Kjell -- ------------------------------ Kjell Rilbe DataDIA AB E-post: kje...@da... Telefon: 08-761 06 55 Mobil: 0733-44 24 64 |
|
From: Alex P. <pes...@ma...> - 2011-03-31 12:15:27
|
On 03/31/11 15:00, Kjell Rilbe wrote: > Generally speaking, I feel it's completely wrong to add something to > an api only because some clients/users would expect it, unless it > actually does something useful in the api. it will only lead to extra > complexity and problems down the line. > > So, if the only reason to add queryInterface is to make Delphi users' > life easier I'd say no, even if I've been a huge Delphi fan ever since > version 1. BTW, what's a problem with writing using Delphi code RAII type for our interface without built-in into compiler support? |
|
From: Vlad K. <hv...@us...> - 2011-03-31 12:46:33
|
> On 03/31/11 15:00, Kjell Rilbe wrote:
>> Generally speaking, I feel it's completely wrong to add something to
>> an api only because some clients/users would expect it, unless it
>> actually does something useful in the api. it will only lead to extra
>> complexity and problems down the line.
>>
>> So, if the only reason to add queryInterface is to make Delphi users'
>> life easier I'd say no, even if I've been a huge Delphi fan ever since
>> version 1.
>
> BTW, what's a problem with writing using Delphi code RAII type for our
> interface without built-in into compiler support?
It is not a *big* problem, no. But it will be very convenient. See simplified
example below :
1. Not compatible with IUnknown.
a) Our public header
class Interface
{
virtual int _cdecl addRef() = 0;
virtual int _cdecl release() = 0;
};
class IFoo : public Interface
{
virtual void _cdecl xxx() = 0;
};
b) Delphi declarations
type
IFBInterface = class
function addRef : Integer; abstract; cdecl;
function release : Integer; abstract; cdecl;
end;
IFoo = class(IFBInterface)
procedure xxx; abstract; cdecl;
end;
TFBInterface = class(TInterfacedObject, IFBInterface)
private:
// IInterface overloads
function _AddRef : Integer;
function _Release : Integer;
// IFBInterface methods
function addRef : Integer;
function release : Integer;
FFBIntf : IFBInterface;
public:
constructor Create(AFBIntf : IFBInterface);
end;
TFoo = class (TFBInterface, IFoo)
private:
FFoo : IFoo;
public
constructor Create(AFoo : IFoo);
// IFoo methods
procedure xxx;
end;
function TFBInterface._AddRef : Integer;
begin
return addRef;
end;
function TFBInterface._Release : Integer;
begin
return release;
end;
function TFBInterface.addRef : Integer;
begin
return FFBIntf.addRef;
end;
function TFBInterface.release : Integer;
begin
return FFBIntf.release;
end;
c) Delphi code example :
var
aFoo : IFoo;
begin
aFoo := TFoo.Create( fbGetMeFoo; )
aFoo.xxx;
end
2. If we became compatible with IUnknown
a) Our public header
class Interface
{
virtual int _stdcall queryInterface(...) = 0;
virtual int _stdcall addRef() = 0;
virtual int _stdcall release() = 0;
};
class IFoo : public Interface
{
virtual void _stdcall xxx() = 0;
};
b) Delphi declarations
IFoo = interface (IInterface)
procedure xxx; stdcall;
end;
c) Delphi code example :
var
aFoo : IFoo;
begin
aFoo := fbGetMeFoo;
aFoo.xxx;
end
Regards,
Vlad
|
|
From: Vlad K. <hv...@us...> - 2011-03-31 11:28:27
|
> On the other hand I see no problems with adding that method to our
> interfaces, specially if it's needed to make Delphi people life easier.
> It does not conflict with our versioning support.
Unfortunately it is not enough. To be binary compatible with IUnknown
(not with Delphi itself but with well known stantard interface) we should use
stdcall also. So, we can be compatible and abandon upgradeInterface, or
not compatible and don't add confusion introducing queryInterface.
Regards,
Vlad
|
|
From: Alex P. <pes...@ma...> - 2011-03-31 12:13:15
|
On 03/31/11 15:28, Vlad Khorsun wrote: >> On the other hand I see no problems with adding that method to our >> interfaces, specially if it's needed to make Delphi people life easier. >> It does not conflict with our versioning support. > Unfortunately it is not enough. To be binary compatible with IUnknown > (not with Delphi itself but with well known stantard interface) we should use > stdcall also. So, we can be compatible and abandon upgradeInterface, or > not compatible and don't add confusion introducing queryInterface. Vlad, if really needed we can make 3 first functions in our interface to use stdcall. This breaks nothing. |
|
From: Vlad K. <hv...@us...> - 2011-03-31 12:21:38
|
> On 03/31/11 15:28, Vlad Khorsun wrote:
>>> On the other hand I see no problems with adding that method to our
>>> interfaces, specially if it's needed to make Delphi people life easier.
>>> It does not conflict with our versioning support.
>> Unfortunately it is not enough. To be binary compatible with IUnknown
>> (not with Delphi itself but with well known stantard interface) we should use
>> stdcall also. So, we can be compatible and abandon upgradeInterface, or
>> not compatible and don't add confusion introducing queryInterface.
>
> Vlad, if really needed we can make 3 first functions in our interface to
> use stdcall. This breaks nothing.
And all other functions still will be cdecl ? Don't looks as beauty to me :(
Regards,
Vlad
PS I'm not insisting on binary compatibility with IUnknown. I just want to make it
clear - are we compatible or not.
|
|
From: Alex P. <pes...@ma...> - 2011-03-31 13:30:39
|
On 03/31/11 16:21, Vlad Khorsun wrote: >> On 03/31/11 15:28, Vlad Khorsun wrote: >>>> On the other hand I see no problems with adding that method to our >>>> interfaces, specially if it's needed to make Delphi people life easier. >>>> It does not conflict with our versioning support. >>> Unfortunately it is not enough. To be binary compatible with IUnknown >>> (not with Delphi itself but with well known stantard interface) we should use >>> stdcall also. So, we can be compatible and abandon upgradeInterface, or >>> not compatible and don't add confusion introducing queryInterface. >> Vlad, if really needed we can make 3 first functions in our interface to >> use stdcall. This breaks nothing. > And all other functions still will be cdecl ? Don't looks as beauty to me :( Vlad, I can agree that this is a bit strange, but if we forget about emotions - absolutely nothing bad. Functions from base Firebird::Interface never require upgrade - they are always present. > Regards, > Vlad > > PS I'm not insisting on binary compatibility with IUnknown. I just want to make it > clear - are we compatible or not. Currently - certainly not. |
|
From: Adriano d. S. F. <adr...@gm...> - 2011-03-31 13:45:55
|
On 31-03-2011 10:30, Alex Peshkoff wrote: > On 03/31/11 16:21, Vlad Khorsun wrote: >>> On 03/31/11 15:28, Vlad Khorsun wrote: >>>>> On the other hand I see no problems with adding that method to our >>>>> interfaces, specially if it's needed to make Delphi people life easier. >>>>> It does not conflict with our versioning support. >>>> Unfortunately it is not enough. To be binary compatible with IUnknown >>>> (not with Delphi itself but with well known stantard interface) we should use >>>> stdcall also. So, we can be compatible and abandon upgradeInterface, or >>>> not compatible and don't add confusion introducing queryInterface. >>> Vlad, if really needed we can make 3 first functions in our interface to >>> use stdcall. This breaks nothing. >> And all other functions still will be cdecl ? Don't looks as beauty to me :( > Vlad, I can agree that this is a bit strange, but if we forget about > emotions - absolutely nothing bad. > Functions from base Firebird::Interface never require upgrade - they are > always present. QueryInterface uses GUIDs, and an interface with a GUID should not change. This is not conceptually compatible with our versioning scheme. Adriano |
|
From: Kjell R. <kje...@da...> - 2011-03-31 13:52:59
Attachments:
kjell_rilbe.vcf
|
Adriano dos Santos Fernandes skriver: > QueryInterface uses GUIDs, and an interface with a GUID should not change. > > This is not conceptually compatible with our versioning scheme. If I, as a mere deadly FB user, may butt in here, I really really think QueryInterface and IUnkown compatibility is not good for FB. 1. FB is multi platform, while IUnknown is inherently tied to Microsoft. (Or am I wrong about this?) 2. IUnknown compatibility would imply a lot of other stuff that FB doesn't want, re. COM etc. Although that may not be required per se, just because of IUnknown compatibility, it is in people's minds very tightly coupled with COM. This is not good. FB is not a COM object and shouldn't be. Ever. Please. ;-) I think QueryInterface and IUnkown would confuse more than help. Kjell -- ------------------------------ Kjell Rilbe DataDIA AB E-post: kje...@da... Telefon: 08-761 06 55 Mobil: 0733-44 24 64 |
|
From: Vlad K. <hv...@us...> - 2011-03-31 14:04:05
|
> 1. FB is multi platform, while IUnknown is inherently tied to Microsoft.
> (Or am I wrong about this?)
Absolutely wrong.
> 2. IUnknown compatibility would imply a lot of other stuff that FB
> doesn't want, re. COM etc.
Wrong again.
> Although that may not be required per se,
> just because of IUnknown compatibility, it is in people's minds very
> tightly coupled with COM. This is not good. FB is not a COM object and
> shouldn't be. Ever. Please. ;-)
Nobody going ever think about COM.
Regards,
Vlad
|
|
From: Kjell R. <kje...@da...> - 2011-03-31 14:11:08
Attachments:
kjell_rilbe.vcf
|
Vlad Khorsun skriver: >> 1. FB is multi platform, while IUnknown is inherently tied to Microsoft. >> (Or am I wrong about this?) > > Absolutely wrong. > >> 2. IUnknown compatibility would imply a lot of other stuff that FB >> doesn't want, re. COM etc. > > Wrong again. > >> Although that may not be required per se, >> just because of IUnknown compatibility, it is in people's minds very >> tightly coupled with COM. This is not good. FB is not a COM object and >> shouldn't be. Ever. Please. ;-) > > Nobody going ever think about COM. So, would you say that this article is misleading: http://en.wikipedia.org/wiki/IUnknown Kjell -- ------------------------------ Kjell Rilbe DataDIA AB E-post: kje...@da... Telefon: 08-761 06 55 Mobil: 0733-44 24 64 |
|
From: Vlad K. <hv...@us...> - 2011-03-31 14:49:42
|
>> Nobody going ever think about COM. > > So, would you say that this article is misleading: > > http://en.wikipedia.org/wiki/IUnknown Article is not misleading. How you read it - probably. It said : In programming, the IUnknown interface is the fundamental interface in the Component Object Model (COM) and not said : COM is fundamental interface for IUnknown and not said COM is required for IUnknown and ever not said IUnknown is impossible without COM Regards, Vlad |
|
From: Kjell R. <kje...@da...> - 2011-03-31 14:59:06
Attachments:
kjell_rilbe.vcf
|
Vlad Khorsun skriver: >> So, would you say that this article is misleading: >> >> http://en.wikipedia.org/wiki/IUnknown > > Article is not misleading. How you read it - probably. > > It said : > > In programming, the IUnknown interface is the fundamental interface in the Component Object Model (COM) > > and not said : > > COM is fundamental interface for IUnknown > > and not said > > COM is required for IUnknown > > and ever not said > > IUnknown is impossible without COM Granted, but IUnknown is in practice very tightly associated with COM. I saw in the article that it's apparently used in some Mac framework, that I assume is totally unrelated to COM, and it's obvious that IUnknown and the semantics around it do not require COM. It's just that I believe that many people tend to think "COM" when they see "IUnkown". As I see it, very few developers will work directly with FB:s API. The vast majority of FB users will work with a component set or other layer between own code and FB. With that in mind, the most important thing for FB is to have an API that's efficient and easy to maintain. Aspects like "easy to use from Delphi" is not that important, because very few people will do that, and those who do probably know how to do it anyway. It's possible that my judgement is wrong here, of course. Kjell -- ------------------------------ Kjell Rilbe DataDIA AB E-post: kje...@da... Telefon: 08-761 06 55 Mobil: 0733-44 24 64 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X