[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: "indexed" COM properties in MysterX?



Returning to something I had raised back in September:

> > Along these lines, I had played with an idea which may or may not be
> > of interest to you: I was curious as to whether it was necessary to
> > distinguish between COM methods and properties at the Scheme level.
> > I found that with some (messily hacked) changes to the MysterX C
> > code, it was possible to invoke methods and properties using the
> > same function, i.e. eliminating the distinction between com-invoke
> > and com-get-property, and maybe even com-set-property (I've
> > forgotten - I did this a few weeks back).

Paul replied:
> It could be done, I think, but the distinction between methods and
> properties is part of the COM mindset.  It might be confusing to
> conflate these ideas in MysterX.

I believe the reason for the COM mindset is that its most prominent client
languages (VB, VBScript, JScript etc.) support statements of the form
"obj.property = x".  They also tend to distinguish between method calls and
property accesses, i.e. obj.method() is OK but obj.method is not, whereas
obj.property is OK.

In short, the entire reason for the method/property distinction in COM is to
support syntax features of the usual client languages.  In Scheme, none of
this applies.  A single function could be used to invoke methods or access
properties.

I think the internal implementation of this (the C code) would still have to
care about the details of what was being accessed, because it's an integral
part of the COM type information.  However, having the MysterX
implementation hide this unnecessary-to-Scheme detail from the Scheme
developer would be a good thing, IMO.

The current functions could be retained for those who want to make the
method/property distinction explicit in their code - what I'm interested in
could be achieved with an additional generalized "com-access" sort of
function which doesn't need to affect anything other than the C
implementation.

I had modified the v103 C code to do this, and it did work.  If I experiment
any further, I'll let you know what I come up with.  It's obviously not any
kind of critical requirement.

Anton