473,842 Members | 1,933 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Another C# critique

I have posted a C# critique at
http://www.heron-language.com/c-sharp-critique.html. To summarize I bring up
the following issues :

- unsafe code
- attributes
- garbage collection
- non-deterministic destructors
- Objects can't exist on the stack
- Type / Reference Types
- Boxing / Unboxing
- Mutability
- Classes as Modules and Programs
- Polymorphism through Class Inheritance
- Interface Delegation
- Interface Extensions
- C# Missing Template Template Parameters
- Late Added Generics
- Source File Layout
- Public Fields
- Special Primitives
- Is it a Property or is it a field?
- Microsoft

I am perhaps guilty somewhat of being a flame baiting troll, but at the same
time I honestly want to improve on the critique.

Thanks in advance for your responses.

--
Christopher Diggins
yet another language designer
http://www.heron-language.com
Nov 15 '05
188 7282

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:ex******** ******@TK2MSFTN GP09.phx.gbl...

"Magnus Lidbom" <ma***********@ hotmail.com> wrote in message
news:0p******** *************** *********@4ax.c om...
On Wed, 4 Feb 2004 03:41:31 -0600, "Daniel O'Connell [C# MVP]"
<onyxkirx@--NOSPAM--comcast.net> wrote:

"Magnus Lidbom" <ma***********@ hotmail.com> wrote in message
news:bv******* *****@ID-204195.news.uni-berlin.de...
>
> "Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
> message news:Oe******** ******@tk2msftn gp13.phx.gbl...


<snip>
That would be a very interesting capability indeed.
In the case of a const implementation I'd prefer compile time
validation for all languages though.

As would I, however I don't think a backup runtime validation would
nessecerily be a bad thing. It would keep sneaky IL attacks, etc at bay.

Agreed.
I really do need to suck it
up and take a look at rotor, see if such a mechanism is possible.

If you could find the time to do that it would be great :)


At the moment I am currently working with mono's c# compiler(I really
prefer
working in C#, so its C# Compiler In C# is a rather nice place to play,
;))
and have added a few basic language features to it, mainly to start to
familiarize myself with compilers. But I do have time and I will grab
rotor
and a few other bits and see waht I can figure out(only thing I hate about
rotor is that I have to install perl). As I work on compilers and the
language I try to post on my blog[1] about whatever I've added(and
hopefully
links to patches soon as well), so assuming I can figure out how to do
this
I'll be posting information there. I will reply here of course, but it may
be a while before anything serious works and it may be easier to find
there(this thread will fade away soon enough).

1. http://dotnetjunkies.com/weblog/doconnell/


Duly bookmarked :)

/Magnus Lidbom

Nov 15 '05 #181
On Wed, 4 Feb 2004 10:53:30 -0600, "Daniel O'Connell [C# MVP]"
<onyxkirx@--NOSPAM--comcast.net> wrote:

"Magnus Lidbom" <ma***********@ hotmail.com> wrote in message
news:d7******* *************** **********@4ax. com...
On Wed, 4 Feb 2004 07:06:06 -0600, "Daniel O'Connell [C# MVP]"
<onyxkirx@--NOSPAM--comcast.net> wrote:
>
>"Frans Bouma" <pe************ ******@xs4all.n l> wrote in message
>news:Xn******* *************** ***********@207 .46.248.16...
>> "Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
>> news:#T******** ******@TK2MSFTN GP09.phx.gbl:
>> > "Frans Bouma" <pe************ ******@xs4all.n l> wrote in message
>> > news:Xn******** *************** **********@207. 46.248.16...
<snip>
>> Const correctness can only be guaranteed at compiletime, IMHO, if
>> you restrict calls to const methods only, on a const object. Atruntime, >> the CLR can check for const correctness via exceptions. The lattershould >> be enough for people who don't want other code to alter an object(tree) >> which is returned by a method.
>>
>> I think giving this choice like an OPTION STRICT kind of setting
>> for the compiler can satisfy every developer. True, you can't call
>> ToString() if you want to have compile time const-checking, however it
>> might be possible to let the compiler check if the code insideToString() >> is harmful to the object or not. (however this might be pretty complex)
>
>As I was discussing with Magnus, it would be possible although it would
>*need* to be done in some compiler agnostic manner.


<snip>

Seems I've failed to make myself clear. I never intended for the
mechanism to perform that type of code analysis. In fact, I don't feel
that would be appropriate as it would allow for contracts to be
violated. What I intended for the validation to check was that the
contract wasn't breached by code in languages that do not themselves
support const:

//const supporting assembly
class Foo
{
private int m_value;
public static const Foo GetInstance(){r eturn new Foo();}
public int Value
{
//declare get const.
get const
{
return m_value;
}
set
{
m_value = value;
}
}
}

//non-supporting assembly. Oddly enough still C#.
class Bar
{
public void FooBar()
{
//Ok, even though myFoo is not declared const, since
//it's a non supporting language. A compiler switch could
//enable this behaviour in supporting languages to ease
//introduction of const correctness into existing code.
//Valid code in a supporting assembly would be:
//const myFoo = Foo.Getinstance ();
Foo myFoo = Foo.Getinstance ();

//OK.
Console.WriteLi ne(myFoo.Value) ;

//Validation fails at compile time.
myFoo.Value = 5;
}
}

Which is basically what I mean, *I think*, just simply that it would be an
external tool of some sort that does the analysis, instead of requiring the
compiler to do it

I Agree. Never meant to imply I didn't.
, that would have two effects, 1) it would be possible for
all compilers to behave correctly without adding alot of extra code and 2)
you could verify const correctness of code yourself. In an environment where
const doesn't exist in the first class it won't be possible to ensure 100%
that code is const correct without doing a full static analysis of the IL.
The above code, as I read it, makes it impossible for languages that don't
use const to use non-const methods on objects. If for no reason other than
it not being possible to apply metadata to an instance. Beyond that,
tracking references would be next to impossible. If that Foo was placed in a
hash table or array list, I very much doubt the compiler could keep track of
it...thinkin g about it now I am not sure that a static tool could either, so
this whole approach may not be feasible. I'm think you're right, unfortunately.
Now, therun time on the other hand
probably could, but again not without some changes to the system. True.
This could be solved at some point, I've been working on a mechanism(still
playing with syntax) for attaching attributes to an instance of an object at
runtime.
Such a feature could, instead of making a const reference or
variable, be used to make a const instance, which would provide a much more
flexible approach to cross language issues than static tools and relying on
a const return attribute. It'd also make it harder to remove const, if you
deny untrusted code permission to modify the attribute set on an instance,
that code couldn't remove const and cause trouble. It would also allow the
runtime to easily detect if an instance is currently const and if you can
modify it.


I'm afraid I don't think that would do the trick. You'd need to be
able to apply it to references, instead of instances, since there are
quite often several references to the same instance, some const, some
not.

Anyway, how would you attach an attribute to an instance? The syntax
would be interesting, but even more so would be how the runtime would
do it. It would be have to be a completely separate mechanism from
what we call attributes in .Net at present I assume? Would it
necessitate changing the memory layout of classes? How about structs?
How would it play with interop and Sequential Layout? This is not
exactly simple :/

Playing around with this in my head I can't come up with anything that
has a chance of working the way const should. It keeps coming back to
that, as far as I am aware, you can't attach information to references
without modifying the runtime representation of a reference. And
changing the runtime representation of references is not what I see in
the future for .Net.

It would be rather a powerful concept though. You could for instance
have the reference hold two pointers instead of one. One to the
instance data and one two the vtable. That would allow for all sorts
of runtime modifications of behaviour. The least powerful of which
would be to be able to implement runtime const checking.

/Magnus Lidbom
Nov 15 '05 #182

"Magnus Lidbom" <ma***********@ hotmail.com> wrote in message
news:ge******** *************** *********@4ax.c om...
On Wed, 4 Feb 2004 10:53:30 -0600, "Daniel O'Connell [C# MVP]"
<onyxkirx@--NOSPAM--comcast.net> wrote:

"Magnus Lidbom" <ma***********@ hotmail.com> wrote in message
news:d7******* *************** **********@4ax. com...
On Wed, 4 Feb 2004 07:06:06 -0600, "Daniel O'Connell [C# MVP]"
<onyxkirx@--NOSPAM--comcast.net> wrote:

>
>"Frans Bouma" <pe************ ******@xs4all.n l> wrote in message
>news:Xn******* *************** ***********@207 .46.248.16...
>> "Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in >> news:#T******** ******@TK2MSFTN GP09.phx.gbl:
>> > "Frans Bouma" <pe************ ******@xs4all.n l> wrote in message
>> > news:Xn******** *************** **********@207. 46.248.16...

<snip>

>> Const correctness can only be guaranteed at compiletime, IMHO, if >> you restrict calls to const methods only, on a const object. Atruntime,
>> the CLR can check for const correctness via exceptions. The latter

should
>> be enough for people who don't want other code to alter an object

(tree)
>> which is returned by a method.
>>
>> I think giving this choice like an OPTION STRICT kind of setting
>> for the compiler can satisfy every developer. True, you can't call
>> ToString() if you want to have compile time const-checking, however it >> might be possible to let the compiler check if the code inside

ToString()
>> is harmful to the object or not. (however this might be pretty complex) >
>As I was discussing with Magnus, it would be possible although it would >*need* to be done in some compiler agnostic manner.

<snip>

Seems I've failed to make myself clear. I never intended for the
mechanism to perform that type of code analysis. In fact, I don't feel
that would be appropriate as it would allow for contracts to be
violated. What I intended for the validation to check was that the
contract wasn't breached by code in languages that do not themselves
support const:

//const supporting assembly
class Foo
{
private int m_value;
public static const Foo GetInstance(){r eturn new Foo();}
public int Value
{
//declare get const.
get const
{
return m_value;
}
set
{
m_value = value;
}
}
}

//non-supporting assembly. Oddly enough still C#.
class Bar
{
public void FooBar()
{
//Ok, even though myFoo is not declared const, since
//it's a non supporting language. A compiler switch could
//enable this behaviour in supporting languages to ease
//introduction of const correctness into existing code.
//Valid code in a supporting assembly would be:
//const myFoo = Foo.Getinstance ();
Foo myFoo = Foo.Getinstance ();

//OK.
Console.WriteLi ne(myFoo.Value) ;

//Validation fails at compile time.
myFoo.Value = 5;
}
}

Which is basically what I mean, *I think*, just simply that it would be anexternal tool of some sort that does the analysis, instead of requiring thecompiler to do it

I Agree. Never meant to imply I didn't.
, that would have two effects, 1) it would be possible for
all compilers to behave correctly without adding alot of extra code and 2)you could verify const correctness of code yourself. In an environment whereconst doesn't exist in the first class it won't be possible to ensure 100%that code is const correct without doing a full static analysis of the IL.The above code, as I read it, makes it impossible for languages that don'tuse const to use non-const methods on objects. If for no reason other thanit not being possible to apply metadata to an instance. Beyond that,
tracking references would be next to impossible. If that Foo was placed in ahash table or array list, I very much doubt the compiler could keep track ofit...thinkin g about it now I am not sure that a static tool could either, sothis whole approach may not be feasible.

I'm think you're right, unfortunately.
Now, therun time on the other hand
probably could, but again not without some changes to the system.

True.
This could be solved at some point, I've been working on a mechanism(stillplaying with syntax) for attaching attributes to an instance of an object atruntime.
Such a feature could, instead of making a const reference or
variable, be used to make a const instance, which would provide a much moreflexible approach to cross language issues than static tools and relying ona const return attribute. It'd also make it harder to remove const, if youdeny untrusted code permission to modify the attribute set on an instance,that code couldn't remove const and cause trouble. It would also allow theruntime to easily detect if an instance is currently const and if you can
modify it.


I'm afraid I don't think that would do the trick. You'd need to be
able to apply it to references, instead of instances, since there are
quite often several references to the same instance, some const, some
not.

Well, it would be a different kind of const. Instead of const references it
would just give const instances. It is a different concept and I don't know
how well it would extend. It does have the benefit of strong const, keeping
it from being cast away, while you loose the ability to change const state
among references.
Anyway, how would you attach an attribute to an instance? The syntax
would be interesting, but even more so would be how the runtime would
do it. It would be have to be a completely separate mechanism from
what we call attributes in .Net at present I assume? Would it
necessitate changing the memory layout of classes? How about structs?
How would it play with interop and Sequential Layout? This is not
exactly simple :/
No, its not simple, which is where the fun is, ;). Most of hte work I've
been doing is targeted at experimentation , both figuring out *how* to do
things and what situations I'm going to come up with where it won't work,
not nessecerily producing somethign that can work(although I am rather fond
of the security statements). Currently I'm thinking that such attributes
would be references stored somewhere in class memory, something like expando
properties but not. Adding a sort of a InstanceAttribu te**, to use C++ style
declarations, to the header that points to a list(or linked list) of
attributes. As far as interop goes, I suppose it would be a Out of band
pointer, where only classes interested coming from a language capable of
dealing with such things would work. Perhaps post fixing attribute data into
the end of the class after its physical allocation would work, as long as
the remote client doesn't start moving data around. There is going to be
limitations no matter how it works.
My current syntax idea is to use keywords. Although I'm not particularly
fond of it, my current on paper is something akin to:

attach <attribute> to <targetObject >
or

object attributedObjec t = new object();
attach new InstanceAttribu te() to attributedObjec t;

The problem is locating and dealing with attributes. There would have to be
a class that does attaching, detaching, and lookups, something in
System.Reflecti on, so it wouldn't be *nessecery* to have a syntax to do it,
but I am interested in the syntax. Playing around with this in my head I can't come up with anything that
has a chance of working the way const should. It keeps coming back to
that, as far as I am aware, you can't attach information to references
without modifying the runtime representation of a reference. And
changing the runtime representation of references is not what I see in
the future for .Net.

It would be rather a powerful concept though. You could for instance
have the reference hold two pointers instead of one. One to the
instance data and one two the vtable. That would allow for all sorts
of runtime modifications of behaviour. The least powerful of which
would be to be able to implement runtime const checking.
I think it would be powerful. You wouldn't have to change the format of the
reference itself, but you *would* have to modify the table a reference
points to. Without finding the info specifically, one would assume that refs
work something like(pseudocode ):

ref Reference;
RefData[] refTable;

RefData = refTable[ref];

public class RefData
{
void* vtable;
void* instanceData
Type* Type;

//and whatever else
}

simply for book keeping, Adding another field on there would be my immediate
solution, assuming it all works right(I havn't dug in deep enough to be
100%). Adding to that wouldn't be impossible if the runtime is well
written(pointer arithmetic is done centrally or by using global constants).
Internal class data layouts shouldn't matter and should be capable of
varying from version to version, they are, after all, internal structures
not meant to be consumed by anything but the runtime itself.

Granted, its unlikely anything I do will effect change in the spec, but it
does give me something to experiment with and room to consider things I
havn't before.

Currently I'm thinkg about security and control. What level of limitations
should be placed on access to such attributes, all read\privledged write?
all read\all write\privledge d detach? Its something else I have to consider.
One could go so far as to enable instance attribute ACL's, specfying a type
and allowed actions

attach new InstanceAttribu teAcl(typeof(My Class),Actions. Attach |
Actions.Detach | Actions.Read) to myRestrictedIns tance;

or extend the security system, it would all have to be considered. That'd be
another use, assuming instance attributes are properly access controlled,
they could be used to grant a given object security rights at runtime based
on various things instead of a type or publisher before runtime. Granted its
utility isn't massive, but it is interesting to me.

But, it keeps me from boredom(if this is what I do for fun, imagine bored,
;)). /Magnus Lidbom

Nov 15 '05 #183
On Wed, 4 Feb 2004 13:09:41 -0600, "Daniel O'Connell [C# MVP]"
<onyxkirx@--NOSPAM--comcast.net> wrote:

"Magnus Lidbom" <ma***********@ hotmail.com> wrote in message
news:ge******* *************** **********@4ax. com...
On Wed, 4 Feb 2004 10:53:30 -0600, "Daniel O'Connell [C# MVP]"
<onyxkirx@--NOSPAM--comcast.net> wrote:
>
>"Magnus Lidbom" <ma***********@ hotmail.com> wrote in message
>news:d7******* *************** **********@4ax. com...
>> On Wed, 4 Feb 2004 07:06:06 -0600, "Daniel O'Connell [C# MVP]"
>> <onyxkirx@--NOSPAM--comcast.net> wrote:
>>
>> >
>> >"Frans Bouma" <pe************ ******@xs4all.n l> wrote in message
>> >news:Xn******* *************** ***********@207 .46.248.16...
>> >> "Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrotein >> >> news:#T******** ******@TK2MSFTN GP09.phx.gbl:
>> >> > "Frans Bouma" <pe************ ******@xs4all.n l> wrote in message
>> >> > news:Xn******** *************** **********@207. 46.248.16...
>>

<snip>
I'm afraid I don't think that would do the trick. You'd need to be
able to apply it to references, instead of instances, since there are
quite often several references to the same instance, some const, some
not.Well, it would be a different kind of const.

Ok.
Instead of const references it
would just give const instances. It is a different concept and I don't know
how well it would extend. It does have the benefit of strong const, keeping
it from being cast away, while you loose the ability to change const state
among references.
This is in my experience where const is most useful. To be honest, I
doubt an instance bound constness would be of much practical use.

Anyway, how would you attach an attribute to an instance? The syntax
would be interesting, but even more so would be how the runtime would
do it. It would be have to be a completely separate mechanism from
what we call attributes in .Net at present I assume? Would it
necessitate changing the memory layout of classes? How about structs?
How would it play with interop and Sequential Layout? This is not
exactly simple :/

No, its not simple, which is where the fun is, ;).

True enough :)
Most of hte work I've
been doing is targeted at experimentation , both figuring out *how* to do
things and what situations I'm going to come up with where it won't work,
not nessecerily producing somethign that can work(although I am rather fond
of the security statements). Currently I'm thinking that such attributes
would be references stored somewhere in class memory, something like expando
properties but not. Adding a sort of a InstanceAttribu te**, to use C++ style
declarations , to the header that points to a list(or linked list) of
attributes. As far as interop goes, I suppose it would be a Out of band
pointer What does out of band mean in this context?
, where only classes interested coming from a language capable of
dealing with such things would work. Perhaps post fixing attribute data into
the end of the class after its physical allocation would work, as long as
the remote client doesn't start moving data around. There is going to be
limitations no matter how it works.
My current syntax idea is to use keywords. Although I'm not particularly
fond of it, my current on paper is something akin to:

attach <attribute> to <targetObject >
or

object attributedObjec t = new object();
attach new InstanceAttribu te() to attributedObjec t;

The problem is locating and dealing with attributes. There would have to be
a class that does attaching, detaching, and lookups, something in
System.Reflect ion, so it wouldn't be *nessecery* to have a syntax to do it,
but I am interested in the syntax.
Playing around with this in my head I can't come up with anything that
has a chance of working the way const should. It keeps coming back to
that, as far as I am aware, you can't attach information to references
without modifying the runtime representation of a reference. And
changing the runtime representation of references is not what I see in
the future for .Net.

It would be rather a powerful concept though. You could for instance
have the reference hold two pointers instead of one. One to the
instance data and one two the vtable. That would allow for all sorts
of runtime modifications of behaviour. The least powerful of which
would be to be able to implement runtime const checking.
I think it would be powerful. You wouldn't have to change the format of the
reference itself, but you *would* have to modify the table a reference
points to. Without finding the info specifically, one would assume that refs
work something like(pseudocode ):

ref Reference;
RefData[] refTable;

RefData = refTable[ref];

public class RefData
{
void* vtable;
void* instanceData
Type* Type;

//and whatever else
}


Actually I'm almost certain that a reference is nothing more than a 32
bit value as far as runtime representation is concerned. I'd expect
the instance to which the pointer points to start with a vtable
pointer, and the vtable to point to the Type. This is just speculation
though.

class vtable
{
Type* type;
//member pointers
}

class reference
{
object* instance;
}

class instance
{
vtable* table;
//member fields
}

If I'm way off here and you're right, then attaching const to
references would be simpler than attaching it to an instance. That
would be nice. Assuming we forget for now things like inlining of
property accessors >:)
simply for book keeping, Adding another field on there would be my immediate
solution, assuming it all works right(I havn't dug in deep enough to be
100%). I believe that all the data in your metacode besides instanceData is
class data, not instance data. So changing it would change the class,
not the instance.
Adding to that wouldn't be impossible if the runtime is well
written(pointe r arithmetic is done centrally or by using global constants).
Internal class data layouts shouldn't matter and should be capable of
varying from version to version, they are, after all, internal structures
not meant to be consumed by anything but the runtime itself.

Granted, its unlikely anything I do will effect change in the spec, but it
does give me something to experiment with and room to consider things I
havn't before. I certainly won't argue that exploring this wouldn't be fun and
rewarding :)
Currently I'm thinkg about security and control. What level of limitations
should be placed on access to such attributes, all read\privledged write?
all read\all write\privledge d detach? Its something else I have to consider.
One could go so far as to enable instance attribute ACL's, specfying a type
and allowed actions

attach new InstanceAttribu teAcl(typeof(My Class),Actions. Attach |
Actions.Deta ch | Actions.Read) to myRestrictedIns tance;

or extend the security system, it would all have to be considered. That'd be
another use, assuming instance attributes are properly access controlled,
they could be used to grant a given object security rights at runtime based
on various things instead of a type or publisher before runtime. Granted its
utility isn't massive, but it is interesting to me.

But, it keeps me from boredom(if this is what I do for fun, imagine bored,
;)).

Well, I'm not spending my free time writing this because I find it
boring either :)

Regards /Magnus Lidbom

Nov 15 '05 #184

"Magnus Lidbom" <ma***********@ hotmail.com> wrote in message
news:tj******** *************** *********@4ax.c om...
On Wed, 4 Feb 2004 13:09:41 -0600, "Daniel O'Connell [C# MVP]"
<onyxkirx@--NOSPAM--comcast.net> wrote:

"Magnus Lidbom" <ma***********@ hotmail.com> wrote in message
news:ge******* *************** **********@4ax. com...
On Wed, 4 Feb 2004 10:53:30 -0600, "Daniel O'Connell [C# MVP]"
<onyxkirx@--NOSPAM--comcast.net> wrote:

>
>"Magnus Lidbom" <ma***********@ hotmail.com> wrote in message
>news:d7******* *************** **********@4ax. com...
>> On Wed, 4 Feb 2004 07:06:06 -0600, "Daniel O'Connell [C# MVP]"
>> <onyxkirx@--NOSPAM--comcast.net> wrote:
>>
>> >
>> >"Frans Bouma" <pe************ ******@xs4all.n l> wrote in message
>> >news:Xn******* *************** ***********@207 .46.248.16...
>> >> "Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net>
wrote
in
>> >> news:#T******** ******@TK2MSFTN GP09.phx.gbl:
>> >> > "Frans Bouma" <pe************ ******@xs4all.n l> wrote in message
>> >> > news:Xn******** *************** **********@207. 46.248.16...
>>
<snip>
I'm afraid I don't think that would do the trick. You'd need to be
able to apply it to references, instead of instances, since there are
quite often several references to the same instance, some const, some
not.Well, it would be a different kind of const.

Ok.
Instead of const references it
would just give const instances. It is a different concept and I don't knowhow well it would extend. It does have the benefit of strong const, keepingit from being cast away, while you loose the ability to change const stateamong references.


This is in my experience where const is most useful. To be honest, I
doubt an instance bound constness would be of much practical use.

Anyway, how would you attach an attribute to an instance? The syntax
would be interesting, but even more so would be how the runtime would
do it. It would be have to be a completely separate mechanism from
what we call attributes in .Net at present I assume? Would it
necessitate changing the memory layout of classes? How about structs?
How would it play with interop and Sequential Layout? This is not
exactly simple :/

No, its not simple, which is where the fun is, ;).

True enough :)
Most of hte work I've
been doing is targeted at experimentation , both figuring out *how* to do
things and what situations I'm going to come up with where it won't work,
not nessecerily producing somethign that can work(although I am rather fondof the security statements). Currently I'm thinking that such attributes
would be references stored somewhere in class memory, something like expandoproperties but not. Adding a sort of a InstanceAttribu te**, to use C++ styledeclarations , to the header that points to a list(or linked list) of
attributes. As far as interop goes, I suppose it would be a Out of band
pointer

What does out of band mean in this context?
, where only classes interested coming from a language capable of
dealing with such things would work. Perhaps post fixing attribute data intothe end of the class after its physical allocation would work, as long as
the remote client doesn't start moving data around. There is going to be
limitations no matter how it works.
My current syntax idea is to use keywords. Although I'm not particularly
fond of it, my current on paper is something akin to:

attach <attribute> to <targetObject >
or

object attributedObjec t = new object();
attach new InstanceAttribu te() to attributedObjec t;

The problem is locating and dealing with attributes. There would have to bea class that does attaching, detaching, and lookups, something in
System.Reflect ion, so it wouldn't be *nessecery* to have a syntax to do it,but I am interested in the syntax.
Playing around with this in my head I can't come up with anything that
has a chance of working the way const should. It keeps coming back to
that, as far as I am aware, you can't attach information to references
without modifying the runtime representation of a reference. And
changing the runtime representation of references is not what I see in
the future for .Net.

It would be rather a powerful concept though. You could for instance
have the reference hold two pointers instead of one. One to the
instance data and one two the vtable. That would allow for all sorts
of runtime modifications of behaviour. The least powerful of which
would be to be able to implement runtime const checking.

I think it would be powerful. You wouldn't have to change the format of thereference itself, but you *would* have to modify the table a reference
points to. Without finding the info specifically, one would assume that refswork something like(pseudocode ):

ref Reference;
RefData[] refTable;

RefData = refTable[ref];

public class RefData
{
void* vtable;
void* instanceData
Type* Type;

//and whatever else
}


Actually I'm almost certain that a reference is nothing more than a 32
bit value as far as runtime representation is concerned. I'd expect
the instance to which the pointer points to start with a vtable
pointer, and the vtable to point to the Type. This is just speculation
though.


Hehe, this is part of what needs to be figured out. The question I think
needs answering most specifically would be is a reference a literal pointer
or an index\lookup value in a table or whatever.
class vtable
{
Type* type;
//member pointers
}

class reference
{
object* instance;
}

class instance
{
vtable* table;
//member fields
}

If I'm way off here and you're right, then attaching const to
references would be simpler than attaching it to an instance. That
would be nice. Assuming we forget for now things like inlining of
property accessors >:)
simply for book keeping, Adding another field on there would be my immediatesolution, assuming it all works right(I havn't dug in deep enough to be
100%).

I believe that all the data in your metacode besides instanceData is
class data, not instance data. So changing it would change the class,
not the instance.


You have a point there, it would probably most specifcially be an implicit
pointer in an objects instance data to its instance attributes(firs t four
bytes). I wasn't thinking clearly about the makeup of the reference. However
I suspect that reference points to a class type in some manner, by Type* or
whatever, if for no reason than to find the vtable and other type
metadata(class attributes, etc). Of course, in theory the vtable could point
to the type or since the vtable pointer would be unique to each type it
could be used to locate the actual type. I am not so familiar with the core
of any language to even offer much of a guess on this, I shall find out
soon.
Adding to that wouldn't be impossible if the runtime is well
written(pointe r arithmetic is done centrally or by using global constants).Internal class data layouts shouldn't matter and should be capable of
varying from version to version, they are, after all, internal structures
not meant to be consumed by anything but the runtime itself.

Granted, its unlikely anything I do will effect change in the spec, but itdoes give me something to experiment with and room to consider things I
havn't before.

I certainly won't argue that exploring this wouldn't be fun and
rewarding :)
Currently I'm thinkg about security and control. What level of limitationsshould be placed on access to such attributes, all read\privledged write?
all read\all write\privledge d detach? Its something else I have to consider.One could go so far as to enable instance attribute ACL's, specfying a typeand allowed actions

attach new InstanceAttribu teAcl(typeof(My Class),Actions. Attach |
Actions.Deta ch | Actions.Read) to myRestrictedIns tance;

or extend the security system, it would all have to be considered. That'd beanother use, assuming instance attributes are properly access controlled,
they could be used to grant a given object security rights at runtime basedon various things instead of a type or publisher before runtime. Granted itsutility isn't massive, but it is interesting to me.

But, it keeps me from boredom(if this is what I do for fun, imagine bored,;)).

Well, I'm not spending my free time writing this because I find it
boring either :)

Regards /Magnus Lidbom

Nov 15 '05 #185
(inline)

Magnus Lidbom <ma***********@ hotmail.com> wrote in
news:d7******** *************** *********@4ax.c om:
Seems I've failed to make myself clear. I never intended for the
mechanism to perform that type of code analysis. In fact, I don't feel
that would be appropriate as it would allow for contracts to be
violated. What I intended for the validation to check was that the
contract wasn't breached by code in languages that do not themselves
support const:

//const supporting assembly
class Foo
{
private int m_value;
public static const Foo GetInstance(){r eturn new Foo();}
public int Value
{
//declare get const.
get const
{
return m_value;
}
set
{
m_value = value;
}
}
}

//non-supporting assembly. Oddly enough still C#.
class Bar
{
public void FooBar()
{
//Ok, even though myFoo is not declared const, since
//it's a non supporting language. A compiler switch could
//enable this behaviour in supporting languages to ease
//introduction of const correctness into existing code.
//Valid code in a supporting assembly would be:
//const myFoo = Foo.Getinstance ();
Foo myFoo = Foo.Getinstance ();

//OK.
Console.WriteLi ne(myFoo.Value) ;

//Validation fails at compile time.
myFoo.Value = 5;
}
}


This is fairly obvious of course, but what about this: (taking your
classes)

//const supporting assembly
class Foo
{
private int m_value;
public static const Foo GetInstance(){r eturn new Foo();}

public void CalculateNewVal ue()
{
m_value = Bar.NewRandomVa lue() * 10;
}

public int Value
{
//declare get const.
get const
{
return m_value;
}
set
{
m_value = value;
}
}
}

Now, CalculateNewVal ue obviously manipulates an instance of Foo's
value. However if you do not want that to happen, you should be able to
specify that. With the GetInstance() method this should be prevented. I
also can't declare CalculateNewVal ue() as const, because then I can never
call it (as I understand it ;)) because it would always alter the state of
the object. (if this is a misunderstandin g, ignore my posting :))

To determine if a call to CalculateNewVal ue() is violating the
contract in a non-const support language, the compiler has to examine
CalculateNewVal ue(), which can be impossible if it's an event<->handler
kind of construction using delegates.

FB

Nov 15 '05 #186
On Thu, 05 Feb 2004 02:27:43 -0800, Frans Bouma
<pe************ ******@xs4all.n l> wrote:
(inline)

Magnus Lidbom <ma***********@ hotmail.com> wrote in
news:d7******* *************** **********@4ax. com:
Seems I've failed to make myself clear. I never intended for the
mechanism to perform that type of code analysis. In fact, I don't feel
that would be appropriate as it would allow for contracts to be
violated. What I intended for the validation to check was that the
contract wasn't breached by code in languages that do not themselves
support const:

//const supporting assembly
class Foo
{
private int m_value;
public static const Foo GetInstance(){r eturn new Foo();}
public int Value
{
//declare get const.
get const
{
return m_value;
}
set
{
m_value = value;
}
}
}

//non-supporting assembly. Oddly enough still C#.
class Bar
{
public void FooBar()
{
//Ok, even though myFoo is not declared const, since
//it's a non supporting language. A compiler switch could
//enable this behaviour in supporting languages to ease
//introduction of const correctness into existing code.
//Valid code in a supporting assembly would be:
//const myFoo = Foo.Getinstance ();
Foo myFoo = Foo.Getinstance ();

//OK.
Console.WriteLi ne(myFoo.Value) ;

//Validation fails at compile time.
myFoo.Value = 5;
}
}
This is fairly obvious of course, but what about this: (taking your
classes)

//const supporting assembly
class Foo
{
private int m_value;
public static const Foo GetInstance(){r eturn new Foo();}

public void CalculateNewVal ue()
{
m_value = Bar.NewRandomVa lue() * 10;
}

public int Value
{
//declare get const.
get const
{
return m_value;
}
set
{
m_value = value;
}
}
}

Now, CalculateNewVal ue obviously manipulates an instance of Foo's
value. However if you do not want that to happen, you should be able to
specify that.

I'm not sure what you mean. If you mean the ability to pass a Foo
reference around upon which CalculateNewVal ue cannot be called, then
thats just a const reference. This is a bit to obviuos though. I
doubt that's what you're getting at.
With the GetInstance() method this should be prevented. I
also can't declare CalculateNewVal ue() as const, because then I can never
call it (as I understand it ;)) because it would always alter the state of
the object. (if this is a misunderstandin g, ignore my posting :)) Actually, you couild't compile the method. It modifies a non mutable
field, so it can't be const.

To determine if a call to CalculateNewVal ue() is violating the
contract in a non-const support language, the compiler has to examine
CalculateNewVa lue(),

No. Just it's declaration. This discussion is probably moot though. My
idea for validating IL from non supporting languages was flawed. See
the other subthread for details.

/Magnus Lidbom
Nov 15 '05 #187
Magnus Lidbom <ma***********@ hotmail.com> wrote in
news:nt******** *************** *********@4ax.c om:
On Thu, 05 Feb 2004 02:27:43 -0800, Frans Bouma
<pe************ ******@xs4all.n l> wrote:
This is fairly obvious of course, but what about this: (taking
your
classes)

//const supporting assembly
class Foo
{
private int m_value;
public static const Foo GetInstance(){r eturn new Foo();}

public void CalculateNewVal ue()
{
m_value = Bar.NewRandomVa lue() * 10;
}

public int Value
{
//declare get const.
get const
{
return m_value;
}
set
{
m_value = value;
}
}
}

Now, CalculateNewVal ue obviously manipulates an instance of
Foo's
value. However if you do not want that to happen, you should be able to
specify that.

I'm not sure what you mean. If you mean the ability to pass a Foo
reference around upon which CalculateNewVal ue cannot be called, then
thats just a const reference. This is a bit to obviuos though. I
doubt that's what you're getting at.


ok, I now see how stupid the idea was I wrote down :) (non-const
pointer to Foo is allowed to call CalculateNewVal ue, const pointer is not,
becuase it is not declared as const which is exactly what I want and can
be done at compile time indeed).

What I tried to illustrate is that a given class has N methods and
a subset of them should not be able to be called if the instance is
returned via a const method/property. If the language calling the class
instance doesn't support const, it's hard for teh compiler to determine
which methods are callable, i.e.: only those methods which are not
mutating the internal object, and without having every method not doing so
being declared as const by the language the class is written in.

FB
Nov 15 '05 #188
On Thu, 05 Feb 2004 10:24:15 -0800, Frans Bouma
<pe************ ******@xs4all.n l> wrote:
Magnus Lidbom <ma***********@ hotmail.com> wrote in
news:nt******* *************** **********@4ax. com:
On Thu, 05 Feb 2004 02:27:43 -0800, Frans Bouma
<pe************ ******@xs4all.n l> wrote:

<snip>

What I tried to illustrate is that a given class has N methods and
a subset of them should not be able to be called if the instance is
returned via a const method/property. I'm assuming you mean a method returning a const reference. Whether
the method itself is const or not is not relevant.
If the language calling the class
instance doesn't support const, it's hard for teh compiler to determine
which methods are callable, Unfortunately, I doubt that it could be done for non supporting
languages. However, a common const validator component, such as
discussed in another subthread, would make adding const to any
language very simple. Using a context dependent definition of simple
of course :)
i.e.: only those methods which are not
mutating the internal object, and without having every method not doing so
being declared as const by the language the class is written in.

I wouldn't expect it too examine non const methods to determine if
calling them might be safe. I'd expect it to disallow calling them
since calling them would be a breach of contract.
Regards /Magnus Lidbom
Nov 15 '05 #189

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

14
3749
by: Long | last post by:
How to include an HTML doc in another HTML doc Problem: to insert the body section of an HTML doc in another HTML document at a specific location. One possible way is to add a WebCharm tag like this: <%@charm:html 20 0 my_services.htm %> When the HTML template is processed by a WebCharm-aware web server, the
19
2561
by: TC | last post by:
Are there any good sites or forums for a web critique? I went to alt.html.critique and it's pretty dead.
9
2290
by: bowsayge | last post by:
Inspired by fb, Bowsayge decided to write a decimal integer to binary string converter. Perhaps some of the experienced C programmers here can critique it. It allocates probably way too much memory, but it should certainly handle 64-bit cpus :) #include <stdio.h> #include <stdlib.h> char * to_binary (unsigned long value) {
39
1947
by: Eric | last post by:
There is a VB.NET critique on the following page: http://www.vb7-critique.741.com/ for those who are interested. Feel free to take a look and share your thoughts. Cheers, Eric. Ps: for those on comp.programming, this may be off topic, but I've posted there because the critique was part of a discussion in that group.
0
9870
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9715
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
10942
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10310
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9452
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
7855
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
7035
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
5696
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
2
4088
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.