🚀 go-pugleaf

"Frederick C. Wilt" <fcwilt@mindspring.com> a �crit dans le message de news: 
4510c1fc$1@newsgroups.borland.com...

| I am new to C# and .NET so bear with me if I don't use the correct terms.
|
| I was writing a C# test app (in BDS2006) using this 3rd party library in a
| .NET DLL. The documentation stated:
|
| ---------------------------------------
| Note that when calling property read methods that require input parameters
| using C#, "get_" must be appended to the property name. This is an
| idiosyncrasy of the C# language and is not a naming convention 
inconsistency
| within this API.
|
| ---------------------------------------
|
| It seems to be the case and I was wondering why. Seems kind of odd to have
| this requirement.

??????????????????!!!!!!!!!!!!!!!!

Interesting :-) I have been using C# for some time now and have never come 
across any such convention.

The normal property declaration is :

class Thing
{
  private string name;

  public string Name
  {
    get { return name; }
    set { name = value; }
  }
}

However, the quote that you make says something about read methods that 
require input parameters; the only thing I can see that satisifies that 
would be an indexer (array property) :

class Thing
{
  private Dictionary<string, Stuff> stuffList;

  public Stuff this[string index]
  {
    get { return stuffList[index]; }
  }
}

But in no case that I know of would you ever call the accessor method, which 
does get compiled to a hidden method called something like get_Stuff.

Do the docs give any examples of what they are talking about ?

Joanna

-- 
Joanna Carter [TeamB]
Consultant Software Engineer 

Hi,

Thanks for the feedback.

I verified that if I try to read from the property directly I get the 
following error message (I have truncated the non-essential parts of the 
message and changed the name of the property to a generic name):

>> [C# Error] WinForm.cs(260): Property, indexer, or event 
>> 'SomePropertyName' is not supported by the language; try directly calling 
>> accessor method...

Sure enough if I call get_SomePropertyName() with the appropriate parameters 
everything is just fine.

I just think its rather odd that a new language like C# would not handle 
properties of all sorts given that properties are not a new concept.

Regards, Frederick C. Wilt



"Joanna Carter [TeamB]" <joanna@not.for.spam> wrote in message 
news:4510e002$1@newsgroups.borland.com...
> "Frederick C. Wilt" <fcwilt@mindspring.com> a �crit dans le message de 
> news:
> 4510c1fc$1@newsgroups.borland.com...
>
> | I am new to C# and .NET so bear with me if I don't use the correct 
> terms.
> |
> | I was writing a C# test app (in BDS2006) using this 3rd party library in 
> a
> | .NET DLL. The documentation stated:
> |
> | ---------------------------------------
> | Note that when calling property read methods that require input 
> parameters
> | using C#, "get_" must be appended to the property name. This is an
> | idiosyncrasy of the C# language and is not a naming convention
> inconsistency
> | within this API.
> |
> | ---------------------------------------
> |
> | It seems to be the case and I was wondering why. Seems kind of odd to 
> have
> | this requirement.
>
> ??????????????????!!!!!!!!!!!!!!!!
>
> Interesting :-) I have been using C# for some time now and have never come
> across any such convention.
>
> The normal property declaration is :
>
> class Thing
> {
>  private string name;
>
>  public string Name
>  {
>    get { return name; }
>    set { name = value; }
>  }
> }
>
> However, the quote that you make says something about read methods that
> require input parameters; the only thing I can see that satisifies that
> would be an indexer (array property) :
>
> class Thing
> {
>  private Dictionary<string, Stuff> stuffList;
>
>  public Stuff this[string index]
>  {
>    get { return stuffList[index]; }
>  }
> }
>
> But in no case that I know of would you ever call the accessor method, 
> which
> does get compiled to a hidden method called something like get_Stuff.
>
> Do the docs give any examples of what they are talking about ?
>
> Joanna
>
> -- 
> Joanna Carter [TeamB]
> Consultant Software Engineer
>
> 

"Frederick C. Wilt" <fcwilt@mindspring.com> a �crit dans le message de news: 
45116e80$1@newsgroups.borland.com...

| >> [C# Error] WinForm.cs(260): Property, indexer, or event
| >> 'SomePropertyName' is not supported by the language; try directly 
calling
| >> accessor method...
|
| Sure enough if I call get_SomePropertyName() with the appropriate 
parameters
| everything is just fine.
|
| I just think its rather odd that a new language like C# would not handle
| properties of all sorts given that properties are not a new concept.

I think you will find that this is not a limitation of C#, but of the 
language that the third-party assembly was written in. Take the time to 
create your own small DLL in C# and try to use it from C#, you will find no 
such problems.

Have another look at the documentation that you cited before :

| Note that when calling property read methods that require input parameters

At this point, I believe there should be a comma in the text, not after 
"C#".

| using C#, "get_" must be appended to the property name.

The correct English word is prepended, not appended; I think this text is 
written by a someone who has a poor command of English and that you need to 
interpret it rather than read it :-)

| This is an idiosyncrasy of the C# language

This is just not true, full stop, period.

| and is not a naming convention inconsistency within this API.

Following on from mly last comment, this is also blatantly untrue.

If you have to call get_SomePropertyName(), then this is a function call, 
not a property, the parentheses at the end indicate that this cannot be a 
property.

My guess is that the language that this assembly was written in does not 
support the concept of properties, insisting instead on the use of getter 
and setter methods.

Is there any indication of the original language of the assembly ? I may be 
totally wrong, but I thought that Delphi for .NET properties had to have 
accessors named like this, but this shouldn't affect what is seen from 
outside of an assembly.

Here is the IL for part of a class written in C# in an assembly that is used 
from other assemblies

.class public abstract auto ansi beforefieldinit MyType
      extends object
{
      .property string Name
      {
            .get instance string Carter.Framework.MyType::get_Name()
      }

...


.method public hidebysig specialname instance string get_Name() cil managed
{
      .maxstack 1
      .locals init (
            [0] string text1)
      L_0000: nop
      L_0001: ldarg.0
      L_0002: ldfld [mscorlib]System.Reflection.PropertyInfo 
Carter.Framework.Property::info
      L_0007: callvirt instance string 
[mscorlib]System.Reflection.MemberInfo::get_Name()
      L_000c: stloc.0
      L_000d: br.s L_000f
      L_000f: ldloc.0
      L_0010: ret
}

So you can see that the IL knows about properties and links the property to 
a getter method.

Here is the Delphi code for that.

public property Name: string read get_Name;

function Property.get_Name: string;
begin
      Result := self.info.Name
end;

...and here is the C# code

public string Name
{
      get
      {
            return this.info.Name;
      }
}

...which you can see doesn't have the concept of a separated method.

But, much more telling is the MC++ code

public: __property System::String __gc* get_Name()
{
      return this->info->Name;
}

My conclusion is that your DLL is written in Managed C++

Joanna

-- 
Joanna Carter [TeamB]
Consultant Software Engineer 

Hi,

So when the error message says "not supported by the language" it is 
referring to the language used for writing the 3rd party assembly and NOT 
the C# language used for my test program?

That seems reasonable given your explanation.

Of course if it was written in managed C++ and is aimed at .NET users I have 
to wonder why. All of the sample programs that came with the library are 
written in C# or VB.NET.

So a message to the author seems to be in order.

Thanks for all the help, Frederick C. Wilt


"Joanna Carter [TeamB]" <joanna@not.for.spam> wrote in message 
news:45118640$1@newsgroups.borland.com...
> "Frederick C. Wilt" <fcwilt@mindspring.com> a �crit dans le message de 
> news:
> 45116e80$1@newsgroups.borland.com...
>
> | >> [C# Error] WinForm.cs(260): Property, indexer, or event
> | >> 'SomePropertyName' is not supported by the language; try directly
> calling
> | >> accessor method...
> |
> | Sure enough if I call get_SomePropertyName() with the appropriate
> parameters
> | everything is just fine.
> |
> | I just think its rather odd that a new language like C# would not handle
> | properties of all sorts given that properties are not a new concept.
>
> I think you will find that this is not a limitation of C#, but of the
> language that the third-party assembly was written in. Take the time to
> create your own small DLL in C# and try to use it from C#, you will find 
> no
> such problems.
>
> Have another look at the documentation that you cited before :
>
> | Note that when calling property read methods that require input 
> parameters
>
> At this point, I believe there should be a comma in the text, not after
> "C#".
>
> | using C#, "get_" must be appended to the property name.
>
> The correct English word is prepended, not appended; I think this text is
> written by a someone who has a poor command of English and that you need 
> to
> interpret it rather than read it :-)
>
> | This is an idiosyncrasy of the C# language
>
> This is just not true, full stop, period.
>
> | and is not a naming convention inconsistency within this API.
>
> Following on from mly last comment, this is also blatantly untrue.
>
> If you have to call get_SomePropertyName(), then this is a function call,
> not a property, the parentheses at the end indicate that this cannot be a
> property.
>
> My guess is that the language that this assembly was written in does not
> support the concept of properties, insisting instead on the use of getter
> and setter methods.
>
> Is there any indication of the original language of the assembly ? I may 
> be
> totally wrong, but I thought that Delphi for .NET properties had to have
> accessors named like this, but this shouldn't affect what is seen from
> outside of an assembly.
>
> Here is the IL for part of a class written in C# in an assembly that is 
> used
> from other assemblies
>
> .class public abstract auto ansi beforefieldinit MyType
>      extends object
> {
>      .property string Name
>      {
>            .get instance string Carter.Framework.MyType::get_Name()
>      }
>
> ...
>
>
> .method public hidebysig specialname instance string get_Name() cil 
> managed
> {
>      .maxstack 1
>      .locals init (
>            [0] string text1)
>      L_0000: nop
>      L_0001: ldarg.0
>      L_0002: ldfld [mscorlib]System.Reflection.PropertyInfo
> Carter.Framework.Property::info
>      L_0007: callvirt instance string
> [mscorlib]System.Reflection.MemberInfo::get_Name()
>      L_000c: stloc.0
>      L_000d: br.s L_000f
>      L_000f: ldloc.0
>      L_0010: ret
> }
>
> So you can see that the IL knows about properties and links the property 
> to
> a getter method.
>
> Here is the Delphi code for that.
>
> public property Name: string read get_Name;
>
> function Property.get_Name: string;
> begin
>      Result := self.info.Name
> end;
>
> ...and here is the C# code
>
> public string Name
> {
>      get
>      {
>            return this.info.Name;
>      }
> }
>
> ...which you can see doesn't have the concept of a separated method.
>
> But, much more telling is the MC++ code
>
> public: __property System::String __gc* get_Name()
> {
>      return this->info->Name;
> }
>
> My conclusion is that your DLL is written in Managed C++
>
> Joanna
>
> -- 
> Joanna Carter [TeamB]
> Consultant Software Engineer
>
> 

Hi again,

OK heard from the author and he states that the library was written using 
VS2003/2005 and is a combination of C# code and VB.NET code.

So I am confused again.

Regards, Frederick C. Wilt

"Joanna Carter [TeamB]" <joanna@not.for.spam> wrote in message 
news:45118640$1@newsgroups.borland.com...
> "Frederick C. Wilt" <fcwilt@mindspring.com> a �crit dans le message de 
> news:
> 45116e80$1@newsgroups.borland.com...
>
> | >> [C# Error] WinForm.cs(260): Property, indexer, or event
> | >> 'SomePropertyName' is not supported by the language; try directly
> calling
> | >> accessor method...
> |
> | Sure enough if I call get_SomePropertyName() with the appropriate
> parameters
> | everything is just fine.
> |
> | I just think its rather odd that a new language like C# would not handle
> | properties of all sorts given that properties are not a new concept.
>
> I think you will find that this is not a limitation of C#, but of the
> language that the third-party assembly was written in. Take the time to
> create your own small DLL in C# and try to use it from C#, you will find 
> no
> such problems.
>
> Have another look at the documentation that you cited before :
>
> | Note that when calling property read methods that require input 
> parameters
>
> At this point, I believe there should be a comma in the text, not after
> "C#".
>
> | using C#, "get_" must be appended to the property name.
>
> The correct English word is prepended, not appended; I think this text is
> written by a someone who has a poor command of English and that you need 
> to
> interpret it rather than read it :-)
>
> | This is an idiosyncrasy of the C# language
>
> This is just not true, full stop, period.
>
> | and is not a naming convention inconsistency within this API.
>
> Following on from mly last comment, this is also blatantly untrue.
>
> If you have to call get_SomePropertyName(), then this is a function call,
> not a property, the parentheses at the end indicate that this cannot be a
> property.
>
> My guess is that the language that this assembly was written in does not
> support the concept of properties, insisting instead on the use of getter
> and setter methods.
>
> Is there any indication of the original language of the assembly ? I may 
> be
> totally wrong, but I thought that Delphi for .NET properties had to have
> accessors named like this, but this shouldn't affect what is seen from
> outside of an assembly.
>
> Here is the IL for part of a class written in C# in an assembly that is 
> used
> from other assemblies
>
> .class public abstract auto ansi beforefieldinit MyType
>      extends object
> {
>      .property string Name
>      {
>            .get instance string Carter.Framework.MyType::get_Name()
>      }
>
> ...
>
>
> .method public hidebysig specialname instance string get_Name() cil 
> managed
> {
>      .maxstack 1
>      .locals init (
>            [0] string text1)
>      L_0000: nop
>      L_0001: ldarg.0
>      L_0002: ldfld [mscorlib]System.Reflection.PropertyInfo
> Carter.Framework.Property::info
>      L_0007: callvirt instance string
> [mscorlib]System.Reflection.MemberInfo::get_Name()
>      L_000c: stloc.0
>      L_000d: br.s L_000f
>      L_000f: ldloc.0
>      L_0010: ret
> }
>
> So you can see that the IL knows about properties and links the property 
> to
> a getter method.
>
> Here is the Delphi code for that.
>
> public property Name: string read get_Name;
>
> function Property.get_Name: string;
> begin
>      Result := self.info.Name
> end;
>
> ...and here is the C# code
>
> public string Name
> {
>      get
>      {
>            return this.info.Name;
>      }
> }
>
> ...which you can see doesn't have the concept of a separated method.
>
> But, much more telling is the MC++ code
>
> public: __property System::String __gc* get_Name()
> {
>      return this->info->Name;
> }
>
> My conclusion is that your DLL is written in Managed C++
>
> Joanna
>
> -- 
> Joanna Carter [TeamB]
> Consultant Software Engineer
>
> 

"Frederick C. Wilt" <fcwilt@mindspring.com> a �crit dans le message de news: 
45118e66$1@newsgroups.borland.com...

| OK heard from the author and he states that the library was written using
| VS2003/2005 and is a combination of C# code and VB.NET code.

Hmmm, if this is only one assembly, then I would doubt the mixture of 
languages, as far as I know, it is only possible to have one language per 
assembly.

| So I am confused again.

As am I. I am writing a massive application, parts of which are held in 
various DLL assemblies, and I have *never* encountered this peculiarity. 
Properties from any type in any assembly are always available by way of 
simple property syntax from whatever calling assembly I could choose.

Can you say what the library is, or if not in public, would you like to let 
me know privately; you've really got my curiosity up on this one :-)

Joanna

-- 
Joanna Carter [TeamB]
Consultant Software Engineer 

Hi,

Do you have any tools that could delve inside the DLL file itself that might 
provide insight? If the author has done something that has created this 
situation I am sure he would like to be told about it. However being so new 
to .NET this is currently out of my realm.

Sometimes I long for the simple days for CP/M. <g>

Thanks, Frederick C. Wilt

"Joanna Carter [TeamB]" <joanna@not.for.spam> wrote in message 
news:4511b000@newsgroups.borland.com...
> "Frederick C. Wilt" <fcwilt@mindspring.com> a �crit dans le message de 
> news:
> 45118e66$1@newsgroups.borland.com...
>
> | OK heard from the author and he states that the library was written 
> using
> | VS2003/2005 and is a combination of C# code and VB.NET code.
>
> Hmmm, if this is only one assembly, then I would doubt the mixture of
> languages, as far as I know, it is only possible to have one language per
> assembly.
>
> | So I am confused again.
>
> As am I. I am writing a massive application, parts of which are held in
> various DLL assemblies, and I have *never* encountered this peculiarity.
> Properties from any type in any assembly are always available by way of
> simple property syntax from whatever calling assembly I could choose.
>
> Can you say what the library is, or if not in public, would you like to 
> let
> me know privately; you've really got my curiosity up on this one :-)
>
> Joanna
>
> -- 
> Joanna Carter [TeamB]
> Consultant Software Engineer
>
> 

"Frederick C. Wilt" <fcwilt@mindspring.com> a �crit dans le message de news: 
4511b3df$1@newsgroups.borland.com...

| Do you have any tools that could delve inside the DLL file itself that 
might
| provide insight? If the author has done something that has created this
| situation I am sure he would like to be told about it. However being so 
new
| to .NET this is currently out of my realm.

I use Lutz Roeder's Reflector. It is free from

http://www.aisto.com/Roeder/DotNet/

If you are not sure what is involved in using it, if you want to send me the 
DLL, I would be interested to take a peek :-)

Joanna

-- 
Joanna Carter [TeamB]
Consultant Software Engineer 

Hi,

Just email your email address and I will provide the DLL. I will be 
interested if you can help me understand what is going on.

Thank you, Frederick C. Wilt 

Frederick C. Wilt wrote:

> Just email your email address and I will provide the DLL. I will be
> interested if you can help me understand what is going on.

There are also some curious bystanders who would be interested in
hearing the results of your and Joanna's discoveries :-)

-- 
Cheers,
David Clegg
dclegg@gmail.com
http://cc.borland.com/Author.aspx?ID=72299

QualityCentral. The best way to bug Borland about bugs.
http://qc.borland.com

"Homer no function beer well without." - Homer Simpson

Joanna Carter [TeamB] wrote:

> Is there any indication of the original language of the assembly ? I
> may be totally wrong, but I thought that Delphi for .NET properties
> had to have accessors named like this, but this shouldn't affect what
> is seen from outside of an assembly.

	.NET requires that accessors are named this way. C# accessors don't
have names in the code, so the C# compiler generates them under the
hood, as your IL example demonstrates. Delphi doesn't require that you
use this naming convention, but will generate .NET-compliant accessors
using this convention if you do not.

-- 
Craig Stuntz [TeamB] � Vertex Systems Corp. � Columbus, OH
  Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
Want to help make Delphi and InterBase better?  Use QC!
  http://qc.borland.com -- Vote for important issues