Another C# critique

[christopher diggins]

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

[Magnus Lidbom]

"Frans Bouma" <pe******************@xs4all.nl> wrote in message
news:Xn*********************************@207.46.24 8.16...

"Magnus Lidbom" <ma***********@hotmail.com> wrote in
news:bv************@ID-204195.news.uni-berlin.de:

"Frans Bouma" <pe******************@xs4all.nl> wrote in message
news:Xn*********************************@207.46.24 8.16...

You can't do that.
These fields have to be set somewhere by code. Up till today you
can't specify accessor operators in interface definitions, you also
can't define get public and set internal for properties. This means
that this kind of information is changeable.

The example is not that good though. At runtime it's sometimes
handy to be able to change persistence information (if that information
is stored inside the entity that is!) In this case the mapping information has a one to one relationship to
the type of the object that is mapped. Duplicating the mapping
information for each entity would mean huge memory consumption and very
bad performance. Is there such a thing as an object relational mapping
framework that duplicates mapping information for each entity?

With my tool, LLBLGen Pro, I supply templates which generate code

Your tool appears to be a code generator. Aren't we comparing apples and
oranges here? Wouldn't a "mapping" in a code generating solution consist of
code? Meaning it uses no memory what so ever per instance?
in 2 different paradigms: selfservicing and adapter. Selfservicing
contains persistence info per entity. adapter uses a central repository
for that. Selfservicing requires this info in the entity because it has to
be able to execute code like this:

CustomerEntity customer = new CustomerEntity("CHOPS"); It requires that the information be available to the class. Not that it be
duplicated for each instance.
that creates an entity object instance of type Customer and fetches the
entity data with PK "CHOPS" from the database into this new entity
instance. This code has to be able to function completely decoupled from a
central repository, What do you mean by repository in this context? An object cache?
so the data is carried with the entity. What data are we talking about here? When I say mapping, I mean things like:
Field A in class X maps to column B in table Y.
Y is an identity column.
Y may not be null.
A is of type.
.............

THe other
model doesn't use this paradigm, as it uses a central 'adapter' class
which handles all actions with the persistent storage and which retrieves
persistence info for an entity at runtime from a central repository
(singleton object store)

However I don't see why it would result in huge memory problems. Huge is subjective. When a class uses an order of magnitude more memory per
instance I call that huge.

class UserPermission
{
private User m_user;
private SecurityObject m_object;
private SecurityLevel m_level;
//methods and properties
}

I'd expect a UserPermission instance itself to occupy not much more than 12
bytes of memory since all fields are references to objects shared by many
UserPermission instances. I'd expect the mapping information to occupy
hundreds of bytes.

The thing is: you don't carry around an entity for a long time that often,
it's not that wise to load 1000s of entity objects into memory anyway, if
you want to load a list of data for example. You then can better use
readonly lists build ontop of entity definitions which fetch data into a
datatable fast. In the framework I mentioned it's perfectly appropriate to fetch large lists
of objects. It also performs quite well. For instance, I should be able to
carry around many million instances of the above sketched class without any
problem what so ever in the sessions of a web application on a rather old
server. It should have no meaningful affect on performance.

on the fly, for example with dynamic
tables some people use, catalogs/tables chosen on the fly etc.

This framework does not support such functionality at the moment. It
might eventually if a compelling need is demonstrated. However, I see no
need to duplicate the mapping information for each entity in order to
implement such functionality. A single new mapping per scenario should
suffice.

The problem is that you should be able to do that on a per-call
basis. Of course, if you as a developer can inject at runtime, mapping
information on a per call basis, it's perfect.

If you mean that the information is gathered on demand and then used
repeatedly, then that is what I currently do.

Should I eventually implement this type of dynamic remapping it would
probably look something like this:

UserVector importedUsers;
//Remap the User class to an import table
using(DataMapper.SetMapping(typeof(User), mappingName) )
{
//Read all users from import table
//I can't wait for generics so I can get rid of these ugly casts.
importedUsers = new UserVector((User[])DataAdapter.List(typeof(User)));
}//Dispose method restores mapping.

//Save users in the default table
DataAdapter.Save(importedUsers);

I agree that duplicating
information in objects is not that great if it's not necessary.
However if
no central object is used, like a central context, broker or other object,
to retrieve/create entity objects, you have to do it this way. I find it hard to believe that you could persuade me that mapping
information should be per instance. I see no need. But I'm not sure we are
talking about the same information.
Of course
you can create a static class which creates at application start the
repository in core and which is consulted by the entity objects, still,
this can lead to some slowdowns in performance. I don't see how fetching a reference to the mapping when necessary could be
slower than duplicating it.
As I said, duplicated
mapping info at runtime is not that much of a problem, as mapping info is
fairly small How do you define small? In relation to the objects mapped or on an absolute
scale?
and entities are not carried around long, at least they
shouldn't be, due to the fact that an entity that's rather old can get out
of sync sooner or later.

This, in my opinion, must be considered on a per case basis. Appropriate
caching is a vital part of most reasonably complex applications in my
experience. Se above example.
I'm guessing we're mostly just misunderstanding each other due to the very
different natures of the implementations. Code generation vs. Runtime
mapping.

/Magnus Lidbom

[christopher diggins]

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2****************@tk2msftngp13.phx.gbl...

While it would be a noble feature, as has been expressed several times by
various MS employees(I can probably still find references if you want 'em)
because .NET & C# didn't have const in the beginning, the vast amount of
existing code(the framework most notably) that has no concept of const may
make it as much of a silly issue as it is in C++(cast it away easily, etc). Realistically, adding const to C# really would mean adding it to the BCL or its usage would be *heavily* marginalized. Just as adding optional exception specs would effectivly do no good because a very large portion of
functionality doesn't have them, its an issue that will have to be
addressed.

I originally tried to leave const out of the language design for Heron, but
without const a couple of problems arrive 1) allowing only primitives to
have constness elevates primitives to a special status, 2) when a design
calls for immutable and mutable instances of the same class we have to
create two separate classes. The alternative, programmer enforced
mutability, adds unneeded complexity and increases the potential for bugs
significantly. I agree though casting away const is generally a very bad
idea. But C++ is all about letting programmers do very strange things.

--
Christopher Diggins
yet another language designer
http://www.heron-language.com

[Daniel O'Connell [C# MVP]]

"Frans Bouma" <pe******************@xs4all.nl> wrote in message
news:Xn*********************************@207.46.24 8.16...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
news:#5**************@tk2msftngp13.phx.gbl:

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP***********************@msnews.microsoft.co m...

I wouldn't be at all surprised to see const correctness in a future
version of C#. While it would be a noble feature, as has been expressed several times
by various MS employees(I can probably still find references if you want
'em) because .NET & C# didn't have const in the beginning, the vast
amount of existing code(the framework most notably) that has no concept
of const may make it as much of a silly issue as it is in C++(cast it
away easily, etc). Realistically, adding const to C# really would mean
adding it to the BCL or its usage would be *heavily* marginalized. Just
as adding optional exception specs would effectivly do no good because a
very large portion of functionality doesn't have them, its an issue that
will have to be addressed.

As a note, this is in response to all three, just don't feel like writing
essentially the same response three times: I find this a non-issue. The thing is: *if* const is added, the
developer using const on his own code passing it to a BCL method will run
into trouble and this is correct. For THAT purpose he has to write a non-
const property. IF the BCL is set up correctly it works with base
classes/known interfaces ONLY anyway which do not specify const at all.

The point I meant to make is that due to the BCL(and other existing code)
not supporting a notion of const, the usage of const will be limited to the
point where it may be *impossible* to use a const reference without casting
it away. At that point I consider const to be a silly limitation. You either
end up with const that doesn't count(const is just a decorator, irrelevent
to reality), or constant casting back and forth. Neither one is attractive.
I would be much more pro-const semantics if it had been done in the first
place instead of trying to wedge it in 3 or 4 versions down the line. It
works right down to object. Object.ToString() is not const, object.Equals is
not const, IEnumerable.GetEnumerator() isn't const(actually, pre-iterators
it often can't be, assuming declarations in iterator doesn't cause a const
violation, iterators should fix that), the list just continues, we all know
these methods are generally const, but the runtime wouldn't. And I'd shudder
at a suggestion to simply hard code types to ignore.
I don't know how const works in inheritance(can you change the const-ness of
an overridden method? I would hope not that seems to be a contract
violation, a method is either const or not, its not a pick and choose
thing), but without additions of the const concept to Object and all
inheritors, you start having to cast away from const to do things you
shouldn't have to worry about. If the notion of const is going to force me
to produce alot of extra casts per object, then its value is diminished
greatly.
Then, if you throw in generics, const can be a real problem. If you can
modify the const-ness of ToString, you'd have to have a generic constraint
something like where T.ToString() is const, or you'd run into odd
issues(calling ToString() on a const reference where ToString() isn't
const).
Const has to be considered and added to the BCL and the runtime, not
nessecerily everywhere but to atleast a few specific places, Object
specifically. A C# only extension will not suffice.

On another note, the syntax probably needs work, I don't particularly like
the C++ style of trailing declarators for most things(when, where, or throws
is fine, it reads ok, const, etc isn't), so figuring out a method to define
a method as both returning a const reference and being a const method.

If const is added to the spec, developers can finally protect
object states of deep object trees or other objects easily and on a per-
property/method basis. This is essential for code working with THAT code.
It has nothing to do with the BCL, because passing a const object to a BCL
method which modifies it is incorrect by definition, so why should it be a
problem, the developer knows it is a const :)

The reason const isn't part of the language is, if I understood
Gunnerson correctly, that interop with other languages is then a problem,
because these other languages don't have a concept of 'const'.

That's all fine and clear but these other languages also don't have
the concept of generics in some cases. Furthermore, the future will
probably ask for features to be added some languages don't support. Should
the syntax of COBOL be the limiter on C#'s syntaxis? I really don't see
why. Sooner or later, MS has to let go of the 'common concept', because
it's nog going to work. Is it a tough call you can't use a C#'s object in
.NET Cobol? perhaps for the .NET cobol users, however if that means that
2000 .NET cobol users can limit C#'s syntax, used by millions, I don't
know but then something is seriously wrong with the vision for .NET.

On this I sincerly agree. Outside of perhaps VB, there is *NO* language that
should have that much hold on C#. A developer would have to accept, just as
with generics(although its kind of annoying), that const isn't CLS compliant
and you will simply have to design that way. It is a limitation but one I do
feel the developer should decide on, not Microsoft. To this end I do feel
that perhaps an additional layer of compliance needs to exist,
CLS+(generics, const, unsigned types, few other bits) perchance. Allowing
you to target a good subset of clients with some assurance(I hate writing
non CLS-Compliant code, but I have to most of the time).
FB

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma

[Frans Bouma]

"Magnus Lidbom" <ma***********@hotmail.com> wrote in
news:bv************@ID-204195.news.uni-berlin.de:

"Frans Bouma" <pe******************@xs4all.nl> wrote in message
news:Xn*********************************@207.46.24 8.16...

>> The example is not that good though. At runtime it's sometimes
>> handy to be able to change persistence information (if that
>> information is stored inside the entity that is!)
> In this case the mapping information has a one to one relationship to
> the type of the object that is mapped. Duplicating the mapping
> information for each entity would mean huge memory consumption and
> very bad performance. Is there such a thing as an object relational
> mapping framework that duplicates mapping information for each
> entity?
With my tool, LLBLGen Pro, I supply templates which generate code

Your tool appears to be a code generator. Aren't we comparing apples and
oranges here? Wouldn't a "mapping" in a code generating solution consist
of code? Meaning it uses no memory what so ever per instance?

Following one paradigm, the instance contains the mapping material,
so it doesn't have to consult any other object to get its stuff persisted.
Although the mapping info is generated into the code, it is inserted via
constructors in the instance. I admit that this is a bit redundant, that's
also why the other paradigm is offered using a central repository for
mapping info, which means that the entity instances do not contain any
mapping info. In normal usage, this is not a problem though. I do not
consider an object graph of 4 million objects 'normal'.

in 2 different paradigms: selfservicing and adapter. Selfservicing
contains persistence info per entity. adapter uses a central repository
for that. Selfservicing requires this info in the entity because it has
to be able to execute code like this:

CustomerEntity customer = new CustomerEntity("CHOPS");

It requires that the information be available to the class. Not that it
be duplicated for each instance.

if you want to store it physically into a variable, it has to. As I
said, it is a bit verbose perhaps, it can be more compact, I'm perfectly
aware of that, however it has advantages for people who want to alter
mapping info at runtime. That's not my prefered choice, but some people
want it ;)

that creates an entity object instance of type Customer and fetches the
entity data with PK "CHOPS" from the database into this new entity
instance. This code has to be able to function completely decoupled
from a central repository,

What do you mean by repository in this context? An object cache?

A store with the mapping data for entity type ABC and its fields.

so the data is carried with the entity.

What data are we talking about here? When I say mapping, I mean things
like: Field A in class X maps to column B in table Y.
Y is an identity column.
Y may not be null.
A is of type.
............

that kind of data indeed. I formulated it wrong, 'data' is not the
entity data itself, it's the mapping info :)

THe other
model doesn't use this paradigm, as it uses a central 'adapter' class
which handles all actions with the persistent storage and which
retrieves persistence info for an entity at runtime from a central
repository (singleton object store)

However I don't see why it would result in huge memory problems.

Huge is subjective. When a class uses an order of magnitude more memory
per instance I call that huge.

class UserPermission
{
private User m_user;
private SecurityObject m_object;
private SecurityLevel m_level;
//methods and properties
}

I'd expect a UserPermission instance itself to occupy not much more
than 12 bytes of memory since all fields are references to objects
shared by many UserPermission instances. I'd expect the mapping
information to occupy hundreds of bytes.

Ok, that's also the case here, I was talking about the mapping info
for the entity fields, like Customer's fields: CustomerID, ContactName
etc.

The problem is that you should be able to do that on a per-call
basis. Of course, if you as a developer can inject at runtime, mapping
information on a per call basis, it's perfect.

If you mean that the information is gathered on demand and then used
repeatedly, then that is what I currently do.

Should I eventually implement this type of dynamic remapping it would
probably look something like this:

UserVector importedUsers;
//Remap the User class to an import table
using(DataMapper.SetMapping(typeof(User), mappingName) )
{
//Read all users from import table
//I can't wait for generics so I can get rid of these ugly casts.

heheh same here ;)
importedUsers = new
UserVector((User[])DataAdapter.List(typeof(User)));
}//Dispose method restores mapping.

//Save users in the default table
DataAdapter.Save(importedUsers);
yes something like that.

I agree that duplicating
information in objects is not that great if it's not necessary.
However if
no central object is used, like a central context, broker or other
object, to retrieve/create entity objects, you have to do it this way.

I find it hard to believe that you could persuade me that mapping
information should be per instance. I see no need. But I'm not sure we
are talking about the same information.

Well, if memory limitations are not an issue (the average asp.net
webapplication is not bogged down by millions of entity objects and their
mapping info for example) you can create a fetch query from the info
directly available in the entity's field objects. If you don't have that,
you have to look up the mapping information for each field. It then
depends on how you've stored your mapping information to make this read is
fast. With mapping info inside the entity, you don't have that.

It's of course also depending on how the entity classes should look
like: abstract base classes with entity field objects or a totally
different approach: clean, developer supplied classes which can only be
filled through reflection for example.

Of course
you can create a static class which creates at application start the
repository in core and which is consulted by the entity objects, still,
this can lead to some slowdowns in performance.

I don't see how fetching a reference to the mapping when necessary could
be slower than duplicating it.

multiple queries generated from a single entity instance: they will
be slower if you have to determine the mapping info each time you are
generating the query.

However, it depends also on how you designed your total framework.
Speed won can be lost in other areas like the CLR has to copy bigger
chunks of memory around, etc.

As I said, duplicated
mapping info at runtime is not that much of a problem, as mapping info
is fairly small

How do you define small? In relation to the objects mapped or on an
absolute scale?

In relation to the data the entity contains in general. Mapping
info is nothing more than a couple of strings and some ints.
I'm guessing we're mostly just misunderstanding each other due to the
very different natures of the implementations. Code generation vs.
Runtime mapping.

I think so. I was more giving an example :) which of course can be
done in another framework in a total different way.

FB
--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma

[Magnus Lidbom]

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2****************@tk2msftngp13.phx.gbl...

"Frans Bouma" <pe******************@xs4all.nl> wrote in message
news:Xn*********************************@207.46.24 8.16...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
news:#5**************@tk2msftngp13.phx.gbl:

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP***********************@msnews.microsoft.co m...

<snip>

The point I meant to make is that due to the BCL(and other existing code)
not supporting a notion of const, the usage of const will be limited to the point where it may be *impossible* to use a const reference without casting it away.
At that point I consider const to be a silly limitation. You either
end up with const that doesn't count(const is just a decorator, irrelevent
to reality), or constant casting back and forth. Neither one is attractive. I would be much more pro-const semantics if it had been done in the first
place instead of trying to wedge it in 3 or 4 versions down the line. It
works right down to object. Object.ToString() is not const, object.Equals is not const, IEnumerable.GetEnumerator() isn't const(actually, pre-iterators
it often can't be, assuming declarations in iterator doesn't cause a const
violation, iterators should fix that), the list just continues, we all know these methods are generally const, but the runtime wouldn't. And I'd shudder at a suggestion to simply hard code types to ignore.
I don't know how const works in inheritance(can you change the const-ness of an overridden method? No. Const is part of the member signature.
I would hope not that seems to be a contract
violation, a method is either const or not, its not a pick and choose
thing), but without additions of the const concept to Object and all
inheritors, you start having to cast away from const to do things you
shouldn't have to worry about. If the notion of const is going to force me
to produce alot of extra casts per object, then its value is diminished
greatly. Agreed.
Then, if you throw in generics, const can be a real problem. If you can
modify the const-ness of ToString, you'd have to have a generic constraint
something like where T.ToString() is const, or you'd run into odd
issues(calling ToString() on a const reference where ToString() isn't
const). This is a non issue since const would be part of the member signature.
Const has to be considered and added to the BCL and the runtime, not
nessecerily everywhere but to atleast a few specific places, Object
specifically. A C# only extension will not suffice. That would certainly be preferrable. I'm not convinced it's a must. I don't
believe there will be quite as much need for casting as you seem to.
On another note, the syntax probably needs work, I don't particularly like
the C++ style of trailing declarators for most things(when, where, or throws is fine, it reads ok, const, etc isn't), so figuring out a method to define a method as both returning a const reference and being a const method. In my opinion the existing and well known syntax should be used. C# has gone
that route so far. I see no reason to change that.
<snip>
The reason const isn't part of the language is, if I understood
Gunnerson correctly, that interop with other languages is then a problem, because these other languages don't have a concept of 'const'. I don't see that this needs to be a problem. Const is a a compile time
thing. Couldn't it be implemented using assembly metadata? So that it
simply isn't visible at all to languages that doesn't support it? Or it
might even be possible to have const enforced at runtime when assemblies
using const are used from languages that don't support const and vice versa.
That's all fine and clear but these other languages also don't have
the concept of generics in some cases. Furthermore, the future will
probably ask for features to be added some languages don't support. Should the syntax of COBOL be the limiter on C#'s syntaxis? I really don't see
why. Sooner or later, MS has to let go of the 'common concept', because
it's nog going to work. Is it a tough call you can't use a C#'s object in .NET Cobol? perhaps for the .NET cobol users, however if that means that
2000 .NET cobol users can limit C#'s syntax, used by millions, I don't
know but then something is seriously wrong with the vision for .NET.

On this I sincerly agree. Outside of perhaps VB, there is *NO* language

that should have that much hold on C#. A developer would have to accept, just as with generics(although its kind of annoying), that const isn't CLS compliant and you will simply have to design that way. It is a limitation but one I do feel the developer should decide on, not Microsoft. To this end I do feel
that perhaps an additional layer of compliance needs to exist,
CLS+(generics, const, unsigned types, few other bits) perchance. Allowing
you to target a good subset of clients with some assurance(I hate writing
non CLS-Compliant code, but I have to most of the time).

Here I too sincerely agree. In one way or another there really needs to be a
way to write interoperable code that uses such features as generics, const,
and operator overloading. If not it means that the powerful mainstream
languages are crippled in order to keep from marginalizing smaller
languages. That does seems silly to me.

Regards /Magnus Lidbom

[Frans Bouma]

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
news:#c**************@tk2msftngp13.phx.gbl:

"Frans Bouma" <pe******************@xs4all.nl> wrote in message
news:Xn*********************************@207.46.24 8.16...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
news:#5**************@tk2msftngp13.phx.gbl:
I find this a non-issue. The thing is: *if* const is added, the
developer using const on his own code passing it to a BCL method will
run into trouble and this is correct. For THAT purpose he has to write
a non- const property. IF the BCL is set up correctly it works with
base classes/known interfaces ONLY anyway which do not specify const at
all.

The point I meant to make is that due to the BCL(and other existing
code) not supporting a notion of const, the usage of const will be
limited to the point where it may be *impossible* to use a const
reference without casting it away. At that point I consider const to be
a silly limitation. You either end up with const that doesn't
count(const is just a decorator, irrelevent to reality), or constant
casting back and forth. Neither one is attractive.

That's not the point. If you write a tool which accepts plugins,
and you want to offer these plugins access to internal contained data but
some data is readonly and other data is not, you can only achieve that by
copying to be readonly data into dummy objects so altering the data has no
effect. With const, this would have been easier.

That's not to say the plugin can't alter the data if it wants to,
however teh tool developer has provided a solid interface which in theory
is correct. The fact that custom objects then are passed to CLR methods
which want to alter them (which is not that common though) and which then
would cause trouble with respect to the const aspect of these objects, is
not important as the developer passing the const objects is in violation.
You can see that as 'limitation' but it's a limitation initiated by the
developer who created the code which produced the object that is const.

I just want to protect the objects exposed to other code from being
altered in given situations and I can now only do that by creating an
immense big pile of copy code and that's no picknick.
I would be much more
pro-const semantics if it had been done in the first place instead of
trying to wedge it in 3 or 4 versions down the line.
Agreed, but that's not reality, so this will not alter anything of
the current situation :) I also simply don't understand why generics
aren't introduced in the first CLR, after all, generics are around for
decades.
Then, if you throw in generics, const can be a real problem. If you can
modify the const-ness of ToString, you'd have to have a generic
constraint something like where T.ToString() is const, or you'd run into
odd issues(calling ToString() on a const reference where ToString()
isn't const).
Const has to be considered and added to the BCL and the runtime, not
nessecerily everywhere but to atleast a few specific places, Object
specifically. A C# only extension will not suffice.

I don't see why not. It's compiler sugar. C++'s const can be
compiled into C code, a language which doesn't contain const. I don't see
why ToString() has any importance in this though. :) It doesn't alter
anything, it just transfers a value to a string format which is returned,
the actual value isn't altered.

FB

[Daniel O'Connell [C# MVP]]

"Magnus Lidbom" <ma***********@hotmail.com> wrote in message
news:bv************@ID-204195.news.uni-berlin.de...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2****************@tk2msftngp13.phx.gbl...

"Frans Bouma" <pe******************@xs4all.nl> wrote in message
news:Xn*********************************@207.46.24 8.16...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
news:#5**************@tk2msftngp13.phx.gbl:
> "Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
> news:MP***********************@msnews.microsoft.co m...
<snip>

The point I meant to make is that due to the BCL(and other existing code) not supporting a notion of const, the usage of const will be limited to the

point where it may be *impossible* to use a const reference without

casting

it away.
At that point I consider const to be a silly limitation. You either
end up with const that doesn't count(const is just a decorator, irrelevent to reality), or constant casting back and forth. Neither one is

attractive.

I would be much more pro-const semantics if it had been done in the first place instead of trying to wedge it in 3 or 4 versions down the line. It
works right down to object. Object.ToString() is not const, object.Equals is

not const, IEnumerable.GetEnumerator() isn't const(actually,

pre-iterators it often can't be, assuming declarations in iterator doesn't cause a const violation, iterators should fix that), the list just continues, we all

know

these methods are generally const, but the runtime wouldn't. And I'd

shudder

at a suggestion to simply hard code types to ignore.
I don't know how const works in inheritance(can you change the const-ness of

an overridden method? No. Const is part of the member signature.

I would hope not that seems to be a contract
violation, a method is either const or not, its not a pick and choose
thing), but without additions of the const concept to Object and all
inheritors, you start having to cast away from const to do things you
shouldn't have to worry about. If the notion of const is going to force

me to produce alot of extra casts per object, then its value is diminished
greatly.

Agreed.

Then, if you throw in generics, const can be a real problem. If you can
modify the const-ness of ToString, you'd have to have a generic constraint something like where T.ToString() is const, or you'd run into odd
issues(calling ToString() on a const reference where ToString() isn't
const).

This is a non issue since const would be part of the member signature.

Const has to be considered and added to the BCL and the runtime, not
nessecerily everywhere but to atleast a few specific places, Object
specifically. A C# only extension will not suffice.

That would certainly be preferrable. I'm not convinced it's a must. I

don't believe there will be quite as much need for casting as you seem to.
The big issue I have is really Equals and ToString. Those are methods that
are used fairly often. Another issue is the == operator. You would have to
control the constness of an == operation(there is no real limitation,
although its expected to not modify objects, operator==(const a, const b)
const would be ideal, but having to implement it everywhere wouldn't be), or
you would have to peform a cast for equality checks. This is one of the risk
points, a language that doesn't support const could provide an == operator
that accepts const by convention(all == operator args are implicitly const),
but ignores it because the language allows it to, that could circumvent
constness. Becuase of this, you could get some *really* weird and unexpected
bugs. If teh runtime performed checking itself it would *really* help.
Anyway, point is, if the simplist tenents of the language are going to
require casting, the design is probably flawed and needs to be redone.

I also feel it would be a great disservice to not include the BCL, while
little languages are probably marginal, its really unrealistic to believe
that VB, MC++, and perhaps a few others(Delphi, etc) are not important for
interoperability and compatibility. If only C# supports full const-ness, the
domain where const is vaild diminishes, and as much as some people want to
believe it, its not a homogeneous C# world.
Beyond that, having to cast simply to use a method on object is BS, IMHO.
Those methods should be available on *EVERY* type, const or not const(they
are all const methods, effectivly). I do not wish to have to cast then, it
starts to make using C# a burden and would probably reduce the usage of
const dramatically.

On another note, the syntax probably needs work, I don't particularly like the C++ style of trailing declarators for most things(when, where, or

throws

is fine, it reads ok, const, etc isn't), so figuring out a method to

define

a method as both returning a const reference and being a const method.

In my opinion the existing and well known syntax should be used. C# has

gone that route so far. I see no reason to change that.

I don't really like it, but it is probably something that can't be changed.
My main reason is it isn't a pleasent syntax and sometimes you have to let
convention go, thats the point of new languages isn't it? I find prefixes
harder to read and easier to mistake, as well as disrupting to my flow of
reading. I consider const an adjective, a descriptor, something that should
go *before* the method(just as virtual, public, etc go), unlike where or
throws, which are constraints and should go after. In my view its a hack to
allow both returning and marking a method as const, not a particularly
eloquent syntax.
however, something like
public const string const Method(); isn't particularly attractive either.
a cleaner syntax may be
[Constant]
public const string Method();

however, to people not familiar with C++, that will suggest that Method is
const, not string. That is an issue I have as well, public const string
certainly looks like its making the Method const, not the return type. Its
just a quirk I don't like, even though I know what it does. Also, two word
type names are not very common in C#. Instead of unsigned int or whatever,
it is uint, ulong. I really don't think it fits into the C# model that well.
While
public const string x;
and
public void Method(const string x);

work with the model
publc const string method() doesn't so well, in that case it seems much more
like a type or Method modifier than a return value modifier.

Again, I doubt many will agree with me. I just don't think that because C++
does it means its nessecerily right.

<snip>
The reason const isn't part of the language is, if I understood
Gunnerson correctly, that interop with other languages is then a problem, because these other languages don't have a concept of 'const'. I don't see that this needs to be a problem. Const is a a compile time
thing. Couldn't it be implemented using assembly metadata? So that it
simply isn't visible at all to languages that doesn't support it? Or it
might even be possible to have const enforced at runtime when assemblies
using const are used from languages that don't support const and vice versa.
If it can be enforced at runtime a developer has to be aware of const, the
language has to support it in some fashion. If it isn't enforced, you could
get a class that claims const but, because it was developed in a const-less
language really isn't. In that case I imagine you wouldn't be pleased when
your object state started changing in const methods. However, due to the
point that the BCL really needs const-ness to make it truly effective,
instead of a burden, it would mean that you couldn't trust const without
examing the source, which in a sense defeats the point. All CLS languages
would atleast have to respect constness, if not provide a way to create
const references of your own.

That's all fine and clear but these other languages also don't have the concept of generics in some cases. Furthermore, the future will
probably ask for features to be added some languages don't support. Should the syntax of COBOL be the limiter on C#'s syntaxis? I really don't see why. Sooner or later, MS has to let go of the 'common concept', because it's nog going to work. Is it a tough call you can't use a C#'s object in .NET Cobol? perhaps for the .NET cobol users, however if that means that 2000 .NET cobol users can limit C#'s syntax, used by millions, I don't
know but then something is seriously wrong with the vision for .NET.

On this I sincerly agree. Outside of perhaps VB, there is *NO* language

that

should have that much hold on C#. A developer would have to accept, just

as

with generics(although its kind of annoying), that const isn't CLS

compliant

and you will simply have to design that way. It is a limitation but one I do

feel the developer should decide on, not Microsoft. To this end I do

feel that perhaps an additional layer of compliance needs to exist,
CLS+(generics, const, unsigned types, few other bits) perchance. Allowing you to target a good subset of clients with some assurance(I hate writing non CLS-Compliant code, but I have to most of the time).

Here I too sincerely agree. In one way or another there really needs to be

a way to write interoperable code that uses such features as generics, const, and operator overloading. If not it means that the powerful mainstream
languages are crippled in order to keep from marginalizing smaller
languages. That does seems silly to me.

Regards /Magnus Lidbom

[Daniel O'Connell [C# MVP]]

"Frans Bouma" <pe******************@xs4all.nl> wrote in message
news:Xn*********************************@207.46.24 8.16...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
news:#c**************@tk2msftngp13.phx.gbl:

"Frans Bouma" <pe******************@xs4all.nl> wrote in message
news:Xn*********************************@207.46.24 8.16...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
news:#5**************@tk2msftngp13.phx.gbl:
I find this a non-issue. The thing is: *if* const is added, the
developer using const on his own code passing it to a BCL method will
run into trouble and this is correct. For THAT purpose he has to write
a non- const property. IF the BCL is set up correctly it works with
base classes/known interfaces ONLY anyway which do not specify const at
all.

The point I meant to make is that due to the BCL(and other existing
code) not supporting a notion of const, the usage of const will be
limited to the point where it may be *impossible* to use a const
reference without casting it away. At that point I consider const to be
a silly limitation. You either end up with const that doesn't
count(const is just a decorator, irrelevent to reality), or constant
casting back and forth. Neither one is attractive.

That's not the point. If you write a tool which accepts plugins,
and you want to offer these plugins access to internal contained data but
some data is readonly and other data is not, you can only achieve that by
copying to be readonly data into dummy objects so altering the data has no
effect. With const, this would have been easier.

That's not to say the plugin can't alter the data if it wants to,
however teh tool developer has provided a solid interface which in theory
is correct. The fact that custom objects then are passed to CLR methods
which want to alter them (which is not that common though) and which then
would cause trouble with respect to the const aspect of these objects, is
not important as the developer passing the const objects is in violation.
You can see that as 'limitation' but it's a limitation initiated by the
developer who created the code which produced the object that is const.

I just want to protect the objects exposed to other code from being
altered in given situations and I can now only do that by creating an
immense big pile of copy code and that's no picknick.

I would be much more
pro-const semantics if it had been done in the first place instead of
trying to wedge it in 3 or 4 versions down the line.

Agreed, but that's not reality, so this will not alter anything of
the current situation :) I also simply don't understand why generics
aren't introduced in the first CLR, after all, generics are around for
decades.

Then, if you throw in generics, const can be a real problem. If you can
modify the const-ness of ToString, you'd have to have a generic
constraint something like where T.ToString() is const, or you'd run into
odd issues(calling ToString() on a const reference where ToString()
isn't const).
Const has to be considered and added to the BCL and the runtime, not
nessecerily everywhere but to atleast a few specific places, Object
specifically. A C# only extension will not suffice.

I don't see why not. It's compiler sugar. C++'s const can be
compiled into C code, a language which doesn't contain const. I don't see
why ToString() has any importance in this though. :) It doesn't alter
anything, it just transfers a value to a string format which is returned,
the actual value isn't altered.

Thats the point, ToString() is *NOT* const, its a non-const method. Meaning
you would haveto cast const-ness away to use it. Thats the annoyance I'm
trying to get at.
While I agree is compiler sugar, I just think its next to useless if it is
only applicable in one language out of many that *could* source the code.
Exposing it as a bit of metadata markup is one thing, you actually could
write static tools to verify this if you were enterprising enough, but
really integrating it into the language and the runtime is something else. I
don't feel that its proper to just start cramming things in as "compiler
sugar" at this point. I would rather see a clean, well thought out
implementation in V5 instead of a hacked, half-assed one in V3. Remeber,
once it goes in, it can never come back out.
A mechanism to attach attributes to instances(a way to track a const that
has been cast out of constness for a period as const) as well as CLS and BCL
support for const-ness would really be a nicer solution than just having a
C# developer *hope* that the const attribute applied to X is valid, and not
just some silly J# twit applying an attribute to non-const code.
Even as a plugin point, do you really want to limit your plugins to C#?
FB

[Magnus Lidbom]

"Frans Bouma" <pe******************@xs4all.nl> wrote in message
news:Xn*********************************@207.46.24 8.16...

"Magnus Lidbom" <ma***********@hotmail.com> wrote in
news:bv************@ID-204195.news.uni-berlin.de:

"Frans Bouma" <pe******************@xs4all.nl> wrote in message
news:Xn*********************************@207.46.24 8.16...

>> The example is not that good though. At runtime it's sometimes
>> handy to be able to change persistence information (if that
>> information is stored inside the entity that is!)
> In this case the mapping information has a one to one relationship to
> the type of the object that is mapped. Duplicating the mapping
> information for each entity would mean huge memory consumption and
> very bad performance. Is there such a thing as an object relational
> mapping framework that duplicates mapping information for each
> entity?

With my tool, LLBLGen Pro, I supply templates which generate code Your tool appears to be a code generator. Aren't we comparing apples and
oranges here? Wouldn't a "mapping" in a code generating solution consist
of code? Meaning it uses no memory what so ever per instance?

Following one paradigm, the instance contains the mapping material,
so it doesn't have to consult any other object to get its stuff persisted.
Although the mapping info is generated into the code, it is inserted via
constructors in the instance. I admit that this is a bit redundant, that's
also why the other paradigm is offered using a central repository for
mapping info, which means that the entity instances do not contain any
mapping info. In normal usage, this is not a problem though. I do not
consider an object graph of 4 million objects 'normal'.

Not the typical case. But certainly one I'd expect to have no problem at all
with for objects such as those I assume you're referring to.

in 2 different paradigms: selfservicing and adapter. Selfservicing
contains persistence info per entity. adapter uses a central repository
for that. Selfservicing requires this info in the entity because it has
to be able to execute code like this:

CustomerEntity customer = new CustomerEntity("CHOPS");

It requires that the information be available to the class. Not that it
be duplicated for each instance.

if you want to store it physically into a variable, it has to.

Why not use a static field for this and an instance field only for when the
default mapping is overridden?

However I don't see why it would result in huge memory problems.

Huge is subjective. When a class uses an order of magnitude more memory
per instance I call that huge.

class UserPermission
{
private User m_user;
private SecurityObject m_object;
private SecurityLevel m_level;
//methods and properties
}

I'd expect a UserPermission instance itself to occupy not much more
than 12 bytes of memory since all fields are references to objects
shared by many UserPermission instances. I'd expect the mapping
information to occupy hundreds of bytes.

Ok, that's also the case here, I was talking about the mapping info
for the entity fields, like Customer's fields: CustomerID, ContactName
etc.

I'm not sure I understand you. The fields in the above class are entity
fields. At least by my, context dependent, definitions of entity. Namely a
mapped class.

Well, if memory limitations are not an issue (the average asp.net
webapplication is not bogged down by millions of entity objects and their
mapping info for example) Bogged down by some 12-100MB of memory usage? I really don't see why. And
that's assuming a _very_ high number of concurrent users and a _very_ high
number of different objects for which access levels need to be defined.
Unless the server actually runs out of memory, memory consumption should
have very little impact on performance. Assuming such a load as discussed,
what would you say would happen to performance if the information was read
from the database for each request instead of cached?
you can create a fetch query from the info
directly available in the entity's field objects. If you don't have that,
you have to look up the mapping information for each field. It then
depends on how you've stored your mapping information to make this read is
fast. With mapping info inside the entity, you don't have that. At worst the cost is a single lookup in a hashtable the size of which is the
number of mapped classes in the project. This is done once for an instance,
not for each field, and only when fetching or persisting single instances.
In other cases it's better optimized.
It's of course also depending on how the entity classes should look
like: abstract base classes with entity field objects or a totally
different approach: clean, developer supplied classes which can only be
filled through reflection for example. At the moment it's the clean approach with an unfortunate need for minimal
custom code when you want lazy loading:

class User
{
private User m_manager;
public User Manager
{
get
{
MappingUtil.EnsureMember(typeof(User), "m_manager");
return m_manager;
}
}
}
This need will be eliminated soon, unfortunately at the cost of requiring
the properties to be virtual(The current way will remain for those situation
where complete control is necessary or just preferred.). I'll also be
adding support for the abstract class approach soon. Mixing the two
approaches will be supported, right down to abstract and concrete properties
in the same class. Unless of course I'm missing something that will shoot
that idea down :)

Of course
you can create a static class which creates at application start the
repository in core and which is consulted by the entity objects, still, this can lead to some slowdowns in performance.

I don't see how fetching a reference to the mapping when necessary could
be slower than duplicating it.

multiple queries generated from a single entity instance: they will
be slower if you have to determine the mapping info each time you are
generating the query.

I don't see why you would need to. Surely static fields could hold the
information for the vast majority of cases? For the runtime remapping case
you could fetch the information once and reuse it for the lifetime of the
instance or remapping. This would require an added instance size of 4 bytes
only.

However, it depends also on how you designed your total framework.
Speed won can be lost in other areas like the CLR has to copy bigger
chunks of memory around, etc.

As I said, duplicated
mapping info at runtime is not that much of a problem, as mapping info
is fairly small

How do you define small? In relation to the objects mapped or on an
absolute scale?

In relation to the data the entity contains in general. Mapping
info is nothing more than a couple of strings and some ints.

And in my case a number of instances of reflection emit generated classes
allowing access to the instances fields. These classes were some 200 times
faster than using FieldInfo for protected fields and 20 times for public
when I last measured(.net 1.0), so I'd say they're essential. They are very
small, but they do add to the total.

<snip>

/Magnus Lidbom

[Magnus Lidbom]

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2****************@TK2MSFTNGP09.phx.gbl...

"Magnus Lidbom" <ma***********@hotmail.com> wrote in message
news:bv************@ID-204195.news.uni-berlin.de...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2****************@tk2msftngp13.phx.gbl...

"Frans Bouma" <pe******************@xs4all.nl> wrote in message
news:Xn*********************************@207.46.24 8.16...
> "Daniel O'Connell [C# MVP]" <[e-mail]> wrote in > news:#5**************@tk2msftngp13.phx.gbl:
> > "Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
> > news:MP***********************@msnews.microsoft.co m...

<snip>

> The reason const isn't part of the language is, if I understood
> Gunnerson correctly, that interop with other languages is then a problem,

> because these other languages don't have a concept of 'const'.

I don't see that this needs to be a problem. Const is a a compile time
thing. Couldn't it be implemented using assembly metadata? So that it
simply isn't visible at all to languages that doesn't support it? Or it
might even be possible to have const enforced at runtime when assemblies
using const are used from languages that don't support const and vice

versa.

If it can be enforced at runtime a developer has to be aware of const, the
language has to support it in some fashion. If it isn't enforced, you

could get a class that claims const but, because it was developed in a const-less language really isn't. In that case I imagine you wouldn't be pleased when
your object state started changing in const methods. However, due to the
point that the BCL really needs const-ness to make it truly effective,
instead of a burden, it would mean that you couldn't trust const without
examing the source, which in a sense defeats the point. All CLS languages
would atleast have to respect constness, if not provide a way to create
const references of your own.

<snip>

Hmm, I should have run further with the assembly metadata idea. There should
be no need for runtime support. Const correctness could be enforced by a
post compile check at the IL level for non-supporting languages. No extra
work would be necccessary for the compilers for these languages beyond
invoking the check upon completion and mapping errors back to reasonably
sensible messages. Should these compilers fail to do so the problem would
be caught by the jit compiler.

Anyone know a reason why this wouldn't work?

/Magnus Lidbom

[Daniel O'Connell [C# MVP]]

"Magnus Lidbom" <ma***********@hotmail.com> wrote in message
news:bv************@ID-204195.news.uni-berlin.de...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2****************@TK2MSFTNGP09.phx.gbl...

"Magnus Lidbom" <ma***********@hotmail.com> wrote in message
news:bv************@ID-204195.news.uni-berlin.de...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2****************@tk2msftngp13.phx.gbl...
>
> "Frans Bouma" <pe******************@xs4all.nl> wrote in message
> news:Xn*********************************@207.46.24 8.16...
> > "Daniel O'Connell [C# MVP]" <[e-mail]> wrote in > > news:#5**************@tk2msftngp13.phx.gbl:
> > > "Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
> > > news:MP***********************@msnews.microsoft.co m...
<snip>

> > The reason const isn't part of the language is, if I understood > > Gunnerson correctly, that interop with other languages is then a
problem,
> > because these other languages don't have a concept of 'const'.
I don't see that this needs to be a problem. Const is a a compile time
thing. Couldn't it be implemented using assembly metadata? So that it
simply isn't visible at all to languages that doesn't support it? Or it might even be possible to have const enforced at runtime when assemblies using const are used from languages that don't support const and vice versa.

If it can be enforced at runtime a developer has to be aware of const, the language has to support it in some fashion. If it isn't enforced, you

could

get a class that claims const but, because it was developed in a

const-less

language really isn't. In that case I imagine you wouldn't be pleased when your object state started changing in const methods. However, due to the
point that the BCL really needs const-ness to make it truly effective,
instead of a burden, it would mean that you couldn't trust const without
examing the source, which in a sense defeats the point. All CLS languages would atleast have to respect constness, if not provide a way to create
const references of your own.

<snip>

Hmm, I should have run further with the assembly metadata idea. There

should be no need for runtime support. Const correctness could be enforced by a
post compile check at the IL level for non-supporting languages. No extra
work would be necccessary for the compilers for these languages beyond
invoking the check upon completion and mapping errors back to reasonably
sensible messages. Should these compilers fail to do so the problem would
be caught by the jit compiler.

The main issue is that you can't apply an attribute to a variable, only to
fields, etc. Which means only class members can have const specified, not
specific fields. To achieve const you need to be able to attach the data to
a particular variable, which requires compiletime supoprt
Anyone know a reason why this wouldn't work?

/Magnus Lidbom

[Magnus Lidbom]

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:ei****************@TK2MSFTNGP12.phx.gbl...

"Magnus Lidbom" <ma***********@hotmail.com> wrote in message
news:bv************@ID-204195.news.uni-berlin.de...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2****************@TK2MSFTNGP09.phx.gbl...

"Magnus Lidbom" <ma***********@hotmail.com> wrote in message
news:bv************@ID-204195.news.uni-berlin.de...
>
> "Daniel O'Connell [C# MVP]" <[e-mail]> wrote in > message news:%2****************@tk2msftngp13.phx.gbl...
> >
> > "Frans Bouma" <pe******************@xs4all.nl> wrote in message
> > news:Xn*********************************@207.46.24 8.16...
> > > "Daniel O'Connell [C# MVP]" <[e-mail]>

wrote in

> > > news:#5**************@tk2msftngp13.phx.gbl:
> > > > "Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
> > > > news:MP***********************@msnews.microsoft.co m...

<snip>
Hmm, I should have run further with the assembly metadata idea. There

should

be no need for runtime support. Const correctness could be enforced by a
post compile check at the IL level for non-supporting languages. No extra work would be necccessary for the compilers for these languages beyond
invoking the check upon completion and mapping errors back to reasonably
sensible messages. Should these compilers fail to do so the problem would be caught by the jit compiler.

The main issue is that you can't apply an attribute to a variable, only to
fields, etc. Which means only class members can have const specified, not
specific fields. To achieve const you need to be able to attach the data
to
a particular variable, which requires compiletime supoprt

Yes, but that would only need to be done when compiling the languages that
do support const since the others can't create their own const references.
Validating use for other languages could be done in a post compile step or
by some sort of plugin for the existing compiler. Don't most languages
compilers use reflection emit to create IL? If that's universal, plugging in
const checking there should do the trick shouldn't it?
Regards /Magnus Lidbom

[Daniel O'Connell [C# MVP]]

"Magnus Lidbom" <ma***********@hotmail.com> wrote in message
news:bv************@ID-204195.news.uni-berlin.de...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:ei****************@TK2MSFTNGP12.phx.gbl...

"Magnus Lidbom" <ma***********@hotmail.com> wrote in message
news:bv************@ID-204195.news.uni-berlin.de...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2****************@TK2MSFTNGP09.phx.gbl...
>
> "Magnus Lidbom" <ma***********@hotmail.com> wrote in message
> news:bv************@ID-204195.news.uni-berlin.de...
> >
> > "Daniel O'Connell [C# MVP]" <[e-mail]> wrote in > > message news:%2****************@tk2msftngp13.phx.gbl...
> > >
> > > "Frans Bouma" <pe******************@xs4all.nl> wrote in message
> > > news:Xn*********************************@207.46.24 8.16...
> > > > "Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
> > > > news:#5**************@tk2msftngp13.phx.gbl:
> > > > > "Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
> > > > > news:MP***********************@msnews.microsoft.co m...

<snip>
Hmm, I should have run further with the assembly metadata idea. There should

be no need for runtime support. Const correctness could be enforced by a post compile check at the IL level for non-supporting languages. No extra work would be necccessary for the compilers for these languages beyond
invoking the check upon completion and mapping errors back to reasonably sensible messages. Should these compilers fail to do so the problem would be caught by the jit compiler.

The main issue is that you can't apply an attribute to a variable, only to fields, etc. Which means only class members can have const specified, not specific fields. To achieve const you need to be able to attach the data
to
a particular variable, which requires compiletime supoprt

Yes, but that would only need to be done when compiling the languages that
do support const since the others can't create their own const references.
Validating use for other languages could be done in a post compile step or
by some sort of plugin for the existing compiler. Don't most languages
compilers use reflection emit to create IL? If that's universal, plugging

in const checking there should do the trick shouldn't it?
Well, I don't know about most compilers, the Mono C# compiler does for sure.
Plugging const into the runtime(both reflection emit and whatever else it
takes, perhaps the ref table) would be nessecery. I'm not sure of *how* to
plug it in, perhaps the experimental Rotor mod that adds const would have
more information on that.
It may be possible, just perhaps a good bit of work(tracking references
could be tricky).
Regards /Magnus Lidbom

[Magnus Lidbom]

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2****************@TK2MSFTNGP09.phx.gbl...

"Magnus Lidbom" <ma***********@hotmail.com> wrote in message
news:bv************@ID-204195.news.uni-berlin.de...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:ei****************@TK2MSFTNGP12.phx.gbl...

"Magnus Lidbom" <ma***********@hotmail.com> wrote in message
news:bv************@ID-204195.news.uni-berlin.de...
>
> "Daniel O'Connell [C# MVP]" <[e-mail]> wrote in > message news:%2****************@TK2MSFTNGP09.phx.gbl...
> >
> > "Magnus Lidbom" <ma***********@hotmail.com> wrote in message
> > news:bv************@ID-204195.news.uni-berlin.de...
> > >
> > > "Daniel O'Connell [C# MVP]" <[e-mail]> wrote

in

> > > message news:%2****************@tk2msftngp13.phx.gbl...
> > > >
> > > > "Frans Bouma" <pe******************@xs4all.nl> wrote in

message > > > > news:Xn*********************************@207.46.24 8.16...
> > > > > "Daniel O'Connell [C# MVP]" <[e-mail]> wrote

> in
> > > > > news:#5**************@tk2msftngp13.phx.gbl:
> > > > > > "Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
> > > > > > news:MP***********************@msnews.microsoft.co m...
>

<snip>

> Hmm, I should have run further with the assembly metadata idea. There should
> be no need for runtime support. Const correctness could be enforced by a > post compile check at the IL level for non-supporting languages. No extra

> work would be necccessary for the compilers for these languages

beyond > invoking the check upon completion and mapping errors back to reasonably > sensible messages. Should these compilers fail to do so the problem

would

> be caught by the jit compiler.
>

The main issue is that you can't apply an attribute to a variable, only to

fields, etc. Which means only class members can have const specified, not specific fields. To achieve const you need to be able to attach the

datato
a particular variable, which requires compiletime supoprt

Yes, but that would only need to be done when compiling the languages

that do support const since the others can't create their own const references. Validating use for other languages could be done in a post compile step or by some sort of plugin for the existing compiler. Don't most languages
compilers use reflection emit to create IL? If that's universal,

plugging in

const checking there should do the trick shouldn't it?
Well, I don't know about most compilers, the Mono C# compiler does for

sure. Plugging const into the runtime(both reflection emit and whatever else it
takes, perhaps the ref table) would be nessecery. I'm not sure of *how* to
plug it in, perhaps the experimental Rotor mod that adds const would have
more information on that.
It may be possible, just perhaps a good bit of work(tracking references
could be tricky).

It would hardly be the first task for the those components that took time or
was tricky though :)

The reason I'm pursuing this is that I seem to remember language
interoperability being quoted as the scale tipping reason for leaving const
out of the language. In my opinion, that argument fails if const correctness
checking can be supplied for any language by modifying reflection emit, or
by supplying a common IL validator. Wait a sec now, thats ilasm.exe for
crying out loud :)

Regards /Magnus Lidbom

[Daniel O'Connell [C# MVP]]

"Magnus Lidbom" <ma***********@hotmail.com> wrote in message
news:bv************@ID-204195.news.uni-berlin.de...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2****************@TK2MSFTNGP09.phx.gbl...

"Magnus Lidbom" <ma***********@hotmail.com> wrote in message
news:bv************@ID-204195.news.uni-berlin.de...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:ei****************@TK2MSFTNGP12.phx.gbl...
>
> "Magnus Lidbom" <ma***********@hotmail.com> wrote in message
> news:bv************@ID-204195.news.uni-berlin.de...
> >
> > "Daniel O'Connell [C# MVP]" <[e-mail]> wrote in > > message news:%2****************@TK2MSFTNGP09.phx.gbl...
> > >
> > > "Magnus Lidbom" <ma***********@hotmail.com> wrote in message
> > > news:bv************@ID-204195.news.uni-berlin.de...
> > > >
> > > > "Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
> > > > message news:%2****************@tk2msftngp13.phx.gbl...
> > > > >
> > > > > "Frans Bouma" <pe******************@xs4all.nl> wrote in message > > > > > news:Xn*********************************@207.46.24 8.16...
> > > > > > "Daniel O'Connell [C# MVP]" <[e-mail]> wrote
> > in
> > > > > > news:#5**************@tk2msftngp13.phx.gbl:
> > > > > > > "Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
> > > > > > > news:MP***********************@msnews.microsoft.co m...
> >

<snip>

> > Hmm, I should have run further with the assembly metadata idea. There > should
> > be no need for runtime support. Const correctness could be enforced

by

a

> > post compile check at the IL level for non-supporting languages.

No extra
> > work would be necccessary for the compilers for these languages beyond > > invoking the check upon completion and mapping errors back to reasonably

> > sensible messages. Should these compilers fail to do so the problem would
> > be caught by the jit compiler.
> >
>
> The main issue is that you can't apply an attribute to a variable, only

to

> fields, etc. Which means only class members can have const

specified, not

> specific fields. To achieve const you need to be able to attach the data >to
> a particular variable, which requires compiletime supoprt
Yes, but that would only need to be done when compiling the languages that do support const since the others can't create their own const references. Validating use for other languages could be done in a post compile

step or by some sort of plugin for the existing compiler. Don't most languages
compilers use reflection emit to create IL? If that's universal,

plugging

in

const checking there should do the trick shouldn't it?

Well, I don't know about most compilers, the Mono C# compiler does for

sure.

Plugging const into the runtime(both reflection emit and whatever else

it takes, perhaps the ref table) would be nessecery. I'm not sure of *how* to plug it in, perhaps the experimental Rotor mod that adds const would have more information on that.
It may be possible, just perhaps a good bit of work(tracking references
could be tricky).

It would hardly be the first task for the those components that took time

or was tricky though :)

The reason I'm pursuing this is that I seem to remember language
interoperability being quoted as the scale tipping reason for leaving const out of the language. In my opinion, that argument fails if const correctness checking can be supplied for any language by modifying reflection emit, or
by supplying a common IL validator. Wait a sec now, thats ilasm.exe for
crying out loud :)
Hehe, sorry, I misread your post. I thought you were propsing a tool to
determine const behavior *now*.
The language issue does exist, though a common, standardized verification
interface for compilers would go a long way. Instead of forcing a compiler
to behave just allow all compilers to accept the same rules\plugins.... Regards /Magnus Lidbom

[Magnus Lidbom]

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:ed**************@TK2MSFTNGP12.phx.gbl...

"Magnus Lidbom" <ma***********@hotmail.com> wrote in message
news:bv************@ID-204195.news.uni-berlin.de...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2****************@TK2MSFTNGP09.phx.gbl...

"Magnus Lidbom" <ma***********@hotmail.com> wrote in message
news:bv************@ID-204195.news.uni-berlin.de...
>
> "Daniel O'Connell [C# MVP]" <[e-mail]> wrote in > message news:ei****************@TK2MSFTNGP12.phx.gbl...
> >
> > "Magnus Lidbom" <ma***********@hotmail.com> wrote in message
> > news:bv************@ID-204195.news.uni-berlin.de...
> > >
> > > "Daniel O'Connell [C# MVP]" <[e-mail]> wrote

in

> > > message news:%2****************@TK2MSFTNGP09.phx.gbl...
> > > >
> > > > "Magnus Lidbom" <ma***********@hotmail.com> wrote in message
> > > > news:bv************@ID-204195.news.uni-berlin.de...
> > > > >
> > > > > "Daniel O'Connell [C# MVP]" <[e-mail]> wrote

> in
> > > > > message news:%2****************@tk2msftngp13.phx.gbl...
> > > > > >
> > > > > > "Frans Bouma" <pe******************@xs4all.nl> wrote in

message

> > > > > > news:Xn*********************************@207.46.24 8.16...
> > > > > > > "Daniel O'Connell [C# MVP]" <[e-mail]> > wrote
> > > in
> > > > > > > news:#5**************@tk2msftngp13.phx.gbl:
> > > > > > > > "Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in

message > > > > > > > > news:MP***********************@msnews.microsoft.co m...
> > >
>

<snip>
The reason I'm pursuing this is that I seem to remember language
interoperability being quoted as the scale tipping reason for leaving

const

out of the language. In my opinion, that argument fails if const

correctness

checking can be supplied for any language by modifying reflection emit, or by supplying a common IL validator. Wait a sec now, thats ilasm.exe for
crying out loud :)

Hehe, sorry, I misread your post. I thought you were propsing a tool to
determine const behavior *now*.

Oh. I don't think I'd care to attempt that :)
The language issue does exist, though a common, standardized verification
interface for compilers would go a long way. Instead of forcing a compiler
to behave just allow all compilers to accept the same rules\plugins....

Exactly. Unless there are stumbling blocks I'm not seeing the
interoperability issue should be a relatively minor one. Such an
implementation might also greatly simplify the migration of the BCL and
other existing code to a const correct state. A compiler flag could be used
to disable the compilers own support for checking const correctness and
delegating it to the generic validator. Since this validator would examine
actual usage of references, not declarations of references , it would allow
for the gradual introduction of const correctness in existing code without
any intermediate code breaking what so ever! Coder error barred of course.
Such a switch seems to me to counter every problem with introducing const
that you've brought up so far.

Am I missing anything?
Anyone have a reason why this wouldn't work?

Regards /Magnus Lidbom

[Daniel O'Connell [C# MVP]]

<snip>

<snip>

The reason I'm pursuing this is that I seem to remember language
interoperability being quoted as the scale tipping reason for leaving const

out of the language. In my opinion, that argument fails if const

correctness

checking can be supplied for any language by modifying reflection emit, or

by supplying a common IL validator. Wait a sec now, thats ilasm.exe

for crying out loud :)
Hehe, sorry, I misread your post. I thought you were propsing a tool to
determine const behavior *now*.

Oh. I don't think I'd care to attempt that :)

The language issue does exist, though a common, standardized

verification interface for compilers would go a long way. Instead of forcing a compiler to behave just allow all compilers to accept the same rules\plugins....

Exactly. Unless there are stumbling blocks I'm not seeing the
interoperability issue should be a relatively minor one. Such an
implementation might also greatly simplify the migration of the BCL and
other existing code to a const correct state. A compiler flag could be

used to disable the compilers own support for checking const correctness and
delegating it to the generic validator. Since this validator would examine
actual usage of references, not declarations of references , it would allow for the gradual introduction of const correctness in existing code without
any intermediate code breaking what so ever! Coder error barred of course.
Such a switch seems to me to counter every problem with introducing const
that you've brought up so far.
I agree, it certainly helps(although I still think *some* BCL work needs to
be done). Am I missing anything?
Anyone have a reason why this wouldn't work?
Nothing I can think of right now. This may be a case wehre the technical
aspect is surmountable while the political one isn't. Convincing the ECMA or
Microsoft that const is important would be the bigger problem.
Regards /Magnus Lidbom

[Magnus Lidbom]

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:Oe**************@tk2msftngp13.phx.gbl...

<snip>

<snip>

> The reason I'm pursuing this is that I seem to remember language
> interoperability being quoted as the scale tipping reason for leaving const
> out of the language. In my opinion, that argument fails if const
correctness
> checking can be supplied for any language by modifying reflection emit,

or

> by supplying a common IL validator. Wait a sec now, thats ilasm.exe for > crying out loud :)
>
Hehe, sorry, I misread your post. I thought you were propsing a tool to determine const behavior *now*.
Oh. I don't think I'd care to attempt that :)

The language issue does exist, though a common, standardized verification interface for compilers would go a long way. Instead of forcing a compiler to behave just allow all compilers to accept the same

rules\plugins....
Exactly. Unless there are stumbling blocks I'm not seeing the
interoperability issue should be a relatively minor one. Such an
implementation might also greatly simplify the migration of the BCL and
other existing code to a const correct state. A compiler flag could be

used

to disable the compilers own support for checking const correctness and
delegating it to the generic validator. Since this validator would examine actual usage of references, not declarations of references , it would

allow

for the gradual introduction of const correctness in existing code without any intermediate code breaking what so ever! Coder error barred of course. Such a switch seems to me to counter every problem with introducing const that you've brought up so far.

I agree, it certainly helps(although I still think *some* BCL work needs

to be done).
No argument there. Such an implementation would not diminish the need for
const correct code in any way. But it would allow the changes to be
introduced gradually, without breaking code along the way. One could go
class by class and insert const where appropriate and everything would still
compile every single step of the way. Barring bugs of course, and finding
those is hardly detrimental :). Compare that method of updating the source
to what it would be like if only declarations where examined to verify const
correctness. Just about every added const would cause breakage.

Am I missing anything?
Anyone have a reason why this wouldn't work?

Nothing I can think of right now. This may be a case where the technical
aspect is surmountable while the political one isn't. Convincing the ECMA

or Microsoft that const is important would be the bigger problem.

It may well be. But unless we're missing something the only meaningful
argument against const I've heard so far seems to be void. Maybe this
solution hasn't occurred to the C# team. After all, it is rather unorthodox.
If the decision to forgo const was made assuming that const would be
guraranteed to break language interoperability and that introducing const
correct code would cause severe code breakage along the way, then this
solution, if feasable, just might make them reconsider.

/Magnus Lidbom

[Frans Bouma]

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
news:Oe**************@TK2MSFTNGP10.phx.gbl:

"Frans Bouma" <pe******************@xs4all.nl> wrote in message
news:Xn*********************************@207.46.24 8.16...

I don't see why not. It's compiler sugar. C++'s const can be
compiled into C code, a language which doesn't contain const. I don't
see why ToString() has any importance in this though. :) It doesn't
alter anything, it just transfers a value to a string format which is
returned, the actual value isn't altered.
Thats the point, ToString() is *NOT* const, its a non-const method.

I know, but that's not too interesting, is it? :) I mean: it
produces a new value, from the old value, it doesn't change the old value,
therefore isn't altering the old value which is constant. I mean this is
also good code:

// foo.Bar is const
int i = foo.Bar;
i++;

I see that as the same as:
string bar = foo.Bar.ToString();

But perhaps we have a misunderstanding going on somewhere ;)
Meaning you would haveto cast const-ness away to use it. Thats the
annoyance I'm trying to get at.
You have to explain to me why because I don't see this. It's my
understanding that ToString() always produces a new value, so I don't see
why I need to cast away const to be able to use it.
While I agree is compiler sugar, I just think its next to useless if it
is only applicable in one language out of many that *could* source the
code. Exposing it as a bit of metadata markup is one thing, you actually
could write static tools to verify this if you were enterprising enough,
but really integrating it into the language and the runtime is something
else. I don't feel that its proper to just start cramming things in as
"compiler sugar" at this point. I would rather see a clean, well thought
out implementation in V5 instead of a hacked, half-assed one in V3.
Remeber, once it goes in, it can never come back out.

I agree that if C# has 'const' and VB.NET doesn't, it's pretty moot
to mark a property's value as const in C# while you can keep altering it
in VB.NET.

However what's the problem by having it in the CLR? Say const
exists and I have this code in class object myBar:

public const Foo MyFoo
{
get { return _myFoo; }
}

Now, when I do this in C#:
Foo bla = myBar.MyFoo;

I can't alter bla's data, because it is const. Now if I do it in
VB.NET:
Dim bla As Foo = myBar.MyFoo

and say, VB.NET doesn't support const and const would be introduced
as a compiler check, the VB.NET developer would be able to alter bla's
data because VB.NET doesn't know of const, and I agree, this is an issue
with compiler-only const checks, so it's not that valuable.

However, if it is placed in the CLR, the CLR could then throw an
exception if the VB.NETdeveloper does this:

bla.MyProperty = newValue

then, although VB.NET doesn't know const, the CLR can forbid the
alternation of that property because bla is const. You can argue that this
is a bad thing, but why would it be a bad thing? I don't see it. The
developer of Bar clearly stated that MyFoo is a const property, and did
that on purpose. Even though VB.NET doesn't understand const, it can't
alter the object, simple as that.

The though thing now is: how does the VB.NET developer know MyFoo
is a const property? This is, I think an issue of documentation. I mean,
if there is no set clause in a property, setting it to a value also gives
an error.

FB
--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma

[Daniel O'Connell [C# MVP]]

"Magnus Lidbom" <ma***********@hotmail.com> wrote in message
news:bv************@ID-204195.news.uni-berlin.de...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:Oe**************@tk2msftngp13.phx.gbl...

<snip>

<snip>

> > The reason I'm pursuing this is that I seem to remember language
> > interoperability being quoted as the scale tipping reason for leaving > const
> > out of the language. In my opinion, that argument fails if const
> correctness
> > checking can be supplied for any language by modifying reflection emit,

or
> > by supplying a common IL validator. Wait a sec now, thats ilasm.exe

for

> > crying out loud :)
> >
> Hehe, sorry, I misread your post. I thought you were propsing a tool to > determine const behavior *now*.

Oh. I don't think I'd care to attempt that :)

> The language issue does exist, though a common, standardized

verification

> interface for compilers would go a long way. Instead of forcing a

compiler

> to behave just allow all compilers to accept the same rules\plugins....
Exactly. Unless there are stumbling blocks I'm not seeing the
interoperability issue should be a relatively minor one. Such an
implementation might also greatly simplify the migration of the BCL

and other existing code to a const correct state. A compiler flag could be

used

to disable the compilers own support for checking const correctness and delegating it to the generic validator. Since this validator would

examine actual usage of references, not declarations of references , it would

allow

for the gradual introduction of const correctness in existing code without any intermediate code breaking what so ever! Coder error barred of course. Such a switch seems to me to counter every problem with introducing const that you've brought up so far.

I agree, it certainly helps(although I still think *some* BCL work needs

to

be done).

No argument there. Such an implementation would not diminish the need for
const correct code in any way. But it would allow the changes to be
introduced gradually, without breaking code along the way. One could go
class by class and insert const where appropriate and everything would

still compile every single step of the way. Barring bugs of course, and finding
those is hardly detrimental :). Compare that method of updating the source
to what it would be like if only declarations where examined to verify const correctness. Just about every added const would cause breakage.

Am I missing anything?
Anyone have a reason why this wouldn't work?
Nothing I can think of right now. This may be a case where the technical
aspect is surmountable while the political one isn't. Convincing the

ECMA or

Microsoft that const is important would be the bigger problem.
It may well be. But unless we're missing something the only meaningful
argument against const I've heard so far seems to be void. Maybe this
solution hasn't occurred to the C# team. After all, it is rather

unorthodox. If the decision to forgo const was made assuming that const would be
guraranteed to break language interoperability and that introducing const
correct code would cause severe code breakage along the way, then this
solution, if feasable, just might make them reconsider.
It might, I'm certain someone from MS is reading this, even if they don't
respond. We'll see if it ever flys anywhere. Of course approaching MS and
the EMCA would be another choice. The rotor const implementation is
something else, inclusions in rotor are more likely to be considered(for
one, MS Employees can look at the source to rotor, I don't think they can't
look at OSS source in their area and I don't know if they can use OSS produc
ts). An examiniation of that would probably yield fruitful as well.
Unfortunate that the C# compiler is in C++ however, I'd rather not go back
to using C++ for anything I can avoid, ;).

Anyway, it also gives rise to an idea that I don't think the framework
currently supports. If the framework was extended to the point where it was
possible to plug in verification units into the run time, something that can
run just before the JIT'er and do analysis on IL on the method being JIT'ed,
such protections and other issues may be additionally avoidable. It would be
a performance issue, to some extent, but as it would only analyze each
method just before the JIT work is done, it would be faster than a scan
before every execution and could be disabled by running ngen for apps with a
vital startup speed. It would be interesting, and an extension point I'd
very much like to see, atleast experimentally. I really do need to suck it
up and take a look at rotor, see if such a mechanism is possible.
/Magnus Lidbom

[Frans Bouma]

"Magnus Lidbom" <ma***********@hotmail.com> wrote in
news:bv************@ID-204195.news.uni-berlin.de:

"Frans Bouma" <pe******************@xs4all.nl> wrote in message
news:Xn*********************************@207.46.24 8.16...

>> in 2 different paradigms: selfservicing and adapter. Selfservicing
>> contains persistence info per entity. adapter uses a central
>> repository for that. Selfservicing requires this info in the entity
>> because it has to be able to execute code like this:
>>
>> CustomerEntity customer = new CustomerEntity("CHOPS");
> It requires that the information be available to the class. Not that
> it be duplicated for each instance.

if you want to store it physically into a variable, it has to.

Why not use a static field for this and an instance field only for when
the default mapping is overridden?

would have been a good solution indeed.

>> However I don't see why it would result in huge memory problems.
> Huge is subjective. When a class uses an order of magnitude more
> memory per instance I call that huge.
>
> class UserPermission
> {
> private User m_user;
> private SecurityObject m_object;
> private SecurityLevel m_level;
> //methods and properties
> }
>
> I'd expect a UserPermission instance itself to occupy not much more
> than 12 bytes of memory since all fields are references to objects
> shared by many UserPermission instances. I'd expect the mapping
> information to occupy hundreds of bytes.

Ok, that's also the case here, I was talking about the mapping info
for the entity fields, like Customer's fields: CustomerID, ContactName
etc.

I'm not sure I understand you. The fields in the above class are entity
fields. At least by my, context dependent, definitions of entity. Namely
a mapped class.

Ah I now understand :) Ok, I consider these fields as members
holding references to related objects, and these relations are coded in
code, not stored into mapping data held somewhere. the only mapping data I
store in every entity (in one template set) is the table field mappings.
Mappings of relations are stored in code via static classes and via
methods. (so myCustomer.Orders fetches lazy loaded all orders related to
myCustomer on the fly, through the generated code.). Indeed, if you do not
generate code you have to keep that info somewhere, it was a
misunderstanding indeed :) I dont' keep that data around.

FB

[Daniel O'Connell [C# MVP]]

"Frans Bouma" <pe******************@xs4all.nl> wrote in message
news:Xn*********************************@207.46.24 8.16...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
news:Oe**************@TK2MSFTNGP10.phx.gbl:

"Frans Bouma" <pe******************@xs4all.nl> wrote in message
news:Xn*********************************@207.46.24 8.16...

I don't see why not. It's compiler sugar. C++'s const can be
compiled into C code, a language which doesn't contain const. I don't
see why ToString() has any importance in this though. :) It doesn't
alter anything, it just transfers a value to a string format which is
returned, the actual value isn't altered.

Thats the point, ToString() is *NOT* const, its a non-const method.

I know, but that's not too interesting, is it? :) I mean: it
produces a new value, from the old value, it doesn't change the old value,
therefore isn't altering the old value which is constant. I mean this is
also good code:

// foo.Bar is const
int i = foo.Bar;
i++;

I see that as the same as:
string bar = foo.Bar.ToString();

But perhaps we have a misunderstanding going on somewhere ;)

Meaning you would haveto cast const-ness away to use it. Thats the
annoyance I'm trying to get at.

You have to explain to me why because I don't see this. It's my
understanding that ToString() always produces a new value, so I don't see
why I need to cast away const to be able to use it.

What I mean, is by my understanding on a const reference to an object, you
can *only* call const methods(otherwise I see little need for a const
modifier, just document it in comments). Without modifying the BCL,
ToString() would not be a const method and be an illegal call. The method
itself *is* const, atleast the default implementation, but the method
signature doesn't guarentee that, meaning that there is no contractual
binding to be const and to the runtime, compilers, and everyone in general
ToString() would effectivly be a non-const method. I wouldn't support or use
a const implementation that simply guessed as to the const-ness of a
method(even by static IL analysis), I want contractual restrictions to that
effect. Such a system would be acceptable to interop with the fringe
case(Cobol or ML maybe), but shouldn't be in C#, VB, Delphi, or C++.
Please correct me if my understanding of const methods is wrong in this
respect.

While I agree is compiler sugar, I just think its next to useless if it
is only applicable in one language out of many that *could* source the
code. Exposing it as a bit of metadata markup is one thing, you actually
could write static tools to verify this if you were enterprising enough,
but really integrating it into the language and the runtime is something
else. I don't feel that its proper to just start cramming things in as
"compiler sugar" at this point. I would rather see a clean, well thought
out implementation in V5 instead of a hacked, half-assed one in V3.
Remeber, once it goes in, it can never come back out.

I agree that if C# has 'const' and VB.NET doesn't, it's pretty moot
to mark a property's value as const in C# while you can keep altering it
in VB.NET.

However what's the problem by having it in the CLR? Say const
exists and I have this code in class object myBar:

public const Foo MyFoo
{
get { return _myFoo; }
}

Now, when I do this in C#:
Foo bla = myBar.MyFoo;

I can't alter bla's data, because it is const. Now if I do it in
VB.NET:
Dim bla As Foo = myBar.MyFoo

and say, VB.NET doesn't support const and const would be introduced
as a compiler check, the VB.NET developer would be able to alter bla's
data because VB.NET doesn't know of const, and I agree, this is an issue
with compiler-only const checks, so it's not that valuable.

However, if it is placed in the CLR, the CLR could then throw an
exception if the VB.NETdeveloper does this:

bla.MyProperty = newValue

then, although VB.NET doesn't know const, the CLR can forbid the
alternation of that property because bla is const. You can argue that this
is a bad thing, but why would it be a bad thing? I don't see it. The
developer of Bar clearly stated that MyFoo is a const property, and did
that on purpose. Even though VB.NET doesn't understand const, it can't
alter the object, simple as that.

The though thing now is: how does the VB.NET developer know MyFoo
is a const property? This is, I think an issue of documentation. I mean,
if there is no set clause in a property, setting it to a value also gives
an error.

FB
--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma

[Frans Bouma]

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
news:#T**************@TK2MSFTNGP09.phx.gbl:

"Frans Bouma" <pe******************@xs4all.nl> wrote in message
news:Xn*********************************@207.46.24 8.16...

You have to explain to me why because I don't see this. It's my
understanding that ToString() always produces a new value, so I don't
see why I need to cast away const to be able to use it.

What I mean, is by my understanding on a const reference to an object,
you can *only* call const methods(otherwise I see little need for a
const modifier, just document it in comments).

In C++ this seems to be the case, if I understand it correctly
(haven't programmed real harcore C++ in years, just C/C++ mix). However
why would C++'s syntaxis be the base of how const should be implemented?
After all, as I see it, the restriction of being able to call only const
methods on a const object is done because that's the only way you can
properly check at compiletime in a reasonable amount of time if a method
really alters the object (and thus violates the contract) or not.

Now, I think there are a couple of reasons people want 'const'
object references: to be sure their code is cost correct, and for example
to be sure no-one alters the returned object reference.

Const correctness can only be guaranteed at compiletime, IMHO, if
you restrict calls to const methods only, on a const object. At runtime,
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)

FB

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma

[Daniel O'Connell [C# MVP]]

"Frans Bouma" <pe******************@xs4all.nl> wrote in message
news:Xn*********************************@207.46.24 8.16...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
news:#T**************@TK2MSFTNGP09.phx.gbl:

"Frans Bouma" <pe******************@xs4all.nl> wrote in message
news:Xn*********************************@207.46.24 8.16...

You have to explain to me why because I don't see this. It's my
understanding that ToString() always produces a new value, so I don't
see why I need to cast away const to be able to use it.

What I mean, is by my understanding on a const reference to an object,
you can *only* call const methods(otherwise I see little need for a
const modifier, just document it in comments).

In C++ this seems to be the case, if I understand it correctly
(haven't programmed real harcore C++ in years, just C/C++ mix). However
why would C++'s syntaxis be the base of how const should be implemented?
After all, as I see it, the restriction of being able to call only const
methods on a const object is done because that's the only way you can
properly check at compiletime in a reasonable amount of time if a method
really alters the object (and thus violates the contract) or not.

Havn't really done much C++ myself in some time, I disliked the C++
inheritence model to the point I wouldn't use it. I was happier working
procedurally. However, as far as the const model goes I think its a
reasonable choice. Const-ness should be a contract, not a runtime determined
property. Now, I think there are a couple of reasons people want 'const'
object references: to be sure their code is cost correct, and for example
to be sure no-one alters the returned object reference.

Const correctness can only be guaranteed at compiletime, IMHO, if
you restrict calls to const methods only, on a const object. At runtime,
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. The code would be
complex enough that forcing every compiler writer who is interested in
constness to implement the whole feature set would be absurd, so either a
compile time tool, preferably via compiler extensions, or a runtime
extension mechanism that would allow verification services *could* do
it(probably both would be ideal), however I think a deeply baked-in solution
would be much more appropriate and complete.

FB

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma

[Magnus Lidbom]

"Frans Bouma" <pe******************@xs4all.nl> wrote in message
news:Xn*********************************@207.46.24 8.16...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
news:#T**************@TK2MSFTNGP09.phx.gbl:

"Frans Bouma" <pe******************@xs4all.nl> wrote in message
news:Xn*********************************@207.46.24 8.16...

You have to explain to me why because I don't see this. It's my
understanding that ToString() always produces a new value, so I don't
see why I need to cast away const to be able to use it.

What I mean, is by my understanding on a const reference to an object,
you can *only* call const methods(otherwise I see little need for a
const modifier, just document it in comments).

In C++ this seems to be the case, if I understand it correctly

Casting barred, your understanding is correct.

<snip>
Const correctness can only be guaranteed at compiletime, IMHO, if
you restrict calls to const methods only, on a const object.
At runtime,
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)

I don't believe implementing it that way would be a good idea. If a method
is not const, that is a statement from the implementer that this method may
alter the state of the instance it is invoked on, even if it doesn't in it's
current implementation. Invoking that method on a const reference is a
breach of contract and should be disallowed except if an explcit cast is
applied.

If you take a look at the subthread above this one, you'll find a discussion
of a potential compile time mechanism that could supply checking of const
even for languages that do not themselves support const It could also supply
as a compiler switch that would allow for gradual introduction of const into
existing code without breakage. The latter would be accomplished by using
the same checks used for non supporting languages instead of a stricter
enforcement of const. Not entirely unlike your idea. In theory, the changes
could be made without any modifications to the CLS. Whether that would be
appropriate is another matter altogther though. The point is that it's not a
change that would break existing compilers.

Regards /Magnus Lidbom

[Magnus Lidbom]

On Wed, 4 Feb 2004 07:06:06 -0600, "Daniel O'Connell [C# MVP]"
<[e-mail]> wrote:

"Frans Bouma" <pe******************@xs4all.nl> wrote in message
news:Xn*********************************@207.46.2 48.16...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
news:#T**************@TK2MSFTNGP09.phx.gbl:

> "Frans Bouma" <pe******************@xs4all.nl> wrote in message
> news:Xn*********************************@207.46.24 8.16...

<snip>
Const correctness can only be guaranteed at compiletime, IMHO, if
you restrict calls to const methods only, on a const object. At runtime,
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(){return 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.WriteLine(myFoo.Value);

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

Regards /Magnus Lidbom

[Magnus Lidbom]

On Wed, 04 Feb 2004 16:58:49 +0100, Magnus Lidbom
<ma***********@hotmail.com> wrote:

<snip>

//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();

This should of course be:
const Foo myFoo = Foo.GetInstance();

/Magnus Lidbom

[Magnus Lidbom]

On Wed, 4 Feb 2004 03:41:31 -0600, "Daniel O'Connell [C# MVP]"
<[e-mail]> wrote:

"Magnus Lidbom" <ma***********@hotmail.com> wrote in message
news:bv************@ID-204195.news.uni-berlin.de...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:Oe**************@tk2msftngp13.phx.gbl...
<snip>

This may be a case where the technical
aspect is surmountable while the political one isn't. Convincing the

ECMA

or

> Microsoft that const is important would be the bigger problem.

It may well be. But unless we're missing something the only meaningful
argument against const I've heard so far seems to be void. Maybe this
solution hasn't occurred to the C# team. After all, it is rather

unorthodox.

If the decision to forgo const was made assuming that const would be
guraranteed to break language interoperability and that introducing const
correct code would cause severe code breakage along the way, then this
solution, if feasable, just might make them reconsider.

It might, I'm certain someone from MS is reading this, even if they don't
respond. We'll see if it ever flys anywhere. Of course approaching MS and
the EMCA would be another choice.

If I had the time necessary to do the research and preparation I
might be tempted to try that. However, my knowledge of compilers is
nowhere near to being up to the task, so it would take quite some time
upgrading that first and then researching this in particular. As is,
finding time for these posts is about what I can manage.

The rotor const implementation is
something else, inclusions in rotor are more likely to be considered(for
one, MS Employees can look at the source to rotor, I don't think they can't
look at OSS source in their area and I don't know if they can use OSS produc
ts). An examiniation of that would probably yield fruitful as well.
Unfortunate that the C# compiler is in C++ however, I'd rather not go back
to using C++ for anything I can avoid, ;).
Anyway, it also gives rise to an idea that I don't think the framework
currently supports. If the framework was extended to the point where it was
possible to plug in verification units into the run time, something that can
run just before the JIT'er and do analysis on IL on the method being JIT'ed,
such protections and other issues may be additionally avoidable. It would be
a performance issue, to some extent, but as it would only analyze each
method just before the JIT work is done, it would be faster than a scan
before every execution and could be disabled by running ngen for apps with a
vital startup speed. It would be interesting, and an extension point I'd
very much like to see, atleast experimentally. 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.
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 :)
Regards /Magnus Lidbom

[Daniel O'Connell [C# MVP]]

"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]"
<[e-mail]> wrote:

"Frans Bouma" <pe******************@xs4all.nl> wrote in message
news:Xn*********************************@207.46.2 48.16...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
news:#T**************@TK2MSFTNGP09.phx.gbl:
> "Frans Bouma" <pe******************@xs4all.nl> wrote in message
> news:Xn*********************************@207.46.24 8.16...
<snip>
Const correctness can only be guaranteed at compiletime, IMHO, if
you restrict calls to const methods only, on a const object. At runtime, 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(){return 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.WriteLine(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, 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...thinking about it now I am not sure that a static tool could either, so
this whole approach may not be feasible. Now, therun time on the other hand
probably could, but again not without some changes to the system.
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.
However, the downsides are that a method could hold onto that instance
reference and use it sometime *after* the attribute has been removed. Regards /Magnus Lidbom

[Daniel O'Connell [C# MVP]]

"Magnus Lidbom" <ma***********@hotmail.com> wrote in message
news:0p********************************@4ax.com...

On Wed, 4 Feb 2004 03:41:31 -0600, "Daniel O'Connell [C# MVP]"
<[e-mail]> wrote:

"Magnus Lidbom" <ma***********@hotmail.com> wrote in message
news:bv************@ID-204195.news.uni-berlin.de...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:Oe**************@tk2msftngp13.phx.gbl...
<snip>
This may be a case where the technical
aspect is surmountable while the political one isn't. Convincing theECMA

or
> Microsoft that const is important would be the bigger problem.

It may well be. But unless we're missing something the only meaningful
argument against const I've heard so far seems to be void. Maybe this
solution hasn't occurred to the C# team. After all, it is rather

unorthodox.

If the decision to forgo const was made assuming that const would be
guraranteed to break language interoperability and that introducing const correct code would cause severe code breakage along the way, then this
solution, if feasable, just might make them reconsider.

It might, I'm certain someone from MS is reading this, even if they don't
respond. We'll see if it ever flys anywhere. Of course approaching MS and
the EMCA would be another choice.

If I had the time necessary to do the research and preparation I
might be tempted to try that. However, my knowledge of compilers is
nowhere near to being up to the task, so it would take quite some time
upgrading that first and then researching this in particular. As is,
finding time for these posts is about what I can manage.

The rotor const implementation is
something else, inclusions in rotor are more likely to be considered(for
one, MS Employees can look at the source to rotor, I don't think they can'tlook at OSS source in their area and I don't know if they can use OSS products). An examiniation of that would probably yield fruitful as well.
Unfortunate that the C# compiler is in C++ however, I'd rather not go backto using C++ for anything I can avoid, ;).
Anyway, it also gives rise to an idea that I don't think the framework
currently supports. If the framework was extended to the point where it waspossible to plug in verification units into the run time, something that canrun just before the JIT'er and do analysis on IL on the method being JIT'ed,such protections and other issues may be additionally avoidable. It would bea performance issue, to some extent, but as it would only analyze each
method just before the JIT work is done, it would be faster than a scan
before every execution and could be disabled by running ngen for apps with avital startup speed. It would be interesting, and an extension point I'd
very much like to see, atleast experimentally.

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.

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/

Regards /Magnus Lidbom

[Magnus Lidbom]

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:ex**************@TK2MSFTNGP09.phx.gbl...

"Magnus Lidbom" <ma***********@hotmail.com> wrote in message
news:0p********************************@4ax.com...

On Wed, 4 Feb 2004 03:41:31 -0600, "Daniel O'Connell [C# MVP]"
<[e-mail]> wrote:

"Magnus Lidbom" <ma***********@hotmail.com> wrote in message
news:bv************@ID-204195.news.uni-berlin.de...
>
> "Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
> message news:Oe**************@tk2msftngp13.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

[Magnus Lidbom]

On Wed, 4 Feb 2004 10:53:30 -0600, "Daniel O'Connell [C# MVP]"
<[e-mail]> 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]"
<[e-mail]> wrote:

>
>"Frans Bouma" <pe******************@xs4all.nl> wrote in message
>news:Xn*********************************@207.46.2 48.16...
>> "Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
>> news:#T**************@TK2MSFTNGP09.phx.gbl:
>> > "Frans Bouma" <pe******************@xs4all.nl> wrote in message
>> > news:Xn*********************************@207.46.24 8.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(){return 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.WriteLine(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...thinking 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

[Daniel O'Connell [C# MVP]]

"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]"
<[e-mail]> 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]"
<[e-mail]> wrote:

>
>"Frans Bouma" <pe******************@xs4all.nl> wrote in message
>news:Xn*********************************@207.46.2 48.16...
>> "Daniel O'Connell [C# MVP]" <[e-mail]> wrote in >> news:#T**************@TK2MSFTNGP09.phx.gbl:
>> > "Frans Bouma" <pe******************@xs4all.nl> wrote in message
>> > news:Xn*********************************@207.46.24 8.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(){return 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.WriteLine(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...thinking 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 InstanceAttribute**, 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 attributedObject = new object();
attach new InstanceAttribute() to attributedObject;

The problem is locating and dealing with attributes. There would have to be
a class that does attaching, detaching, and lookups, something in
System.Reflection, 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\privledged 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 InstanceAttributeAcl(typeof(MyClass),Actions.Attac h |
Actions.Detach | Actions.Read) to myRestrictedInstance;

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

[Magnus Lidbom]

On Wed, 4 Feb 2004 13:09:41 -0600, "Daniel O'Connell [C# MVP]"
<[e-mail]> 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]"
<[e-mail]> 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]"
>> <[e-mail]> wrote:
>>
>> >
>> >"Frans Bouma" <pe******************@xs4all.nl> wrote in message
>> >news:Xn*********************************@207.46.2 48.16...
>> >> "Daniel O'Connell [C# MVP]" <[e-mail]> wrotein >> >> news:#T**************@TK2MSFTNGP09.phx.gbl:
>> >> > "Frans Bouma" <pe******************@xs4all.nl> wrote in message
>> >> > news:Xn*********************************@207.46.24 8.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 InstanceAttribute**, 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 attributedObject = new object();
attach new InstanceAttribute() to attributedObject;

The problem is locating and dealing with attributes. There would have to be
a class that does attaching, detaching, and lookups, something in
System.Reflection, 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(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. 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\privledged 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 InstanceAttributeAcl(typeof(MyClass),Actions.Attac h |
Actions.Detach | Actions.Read) to myRestrictedInstance;

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

[Daniel O'Connell [C# MVP]]

"Magnus Lidbom" <ma***********@hotmail.com> wrote in message
news:tj********************************@4ax.com...

On Wed, 4 Feb 2004 13:09:41 -0600, "Daniel O'Connell [C# MVP]"
<[e-mail]> 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]"
<[e-mail]> 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]"
>> <[e-mail]> wrote:
>>
>> >
>> >"Frans Bouma" <pe******************@xs4all.nl> wrote in message
>> >news:Xn*********************************@207.46.2 48.16...
>> >> "Daniel O'Connell [C# MVP]" <[e-mail]>

wrote

in

>> >> news:#T**************@TK2MSFTNGP09.phx.gbl:
>> >> > "Frans Bouma" <pe******************@xs4all.nl> wrote in message
>> >> > news:Xn*********************************@207.46.24 8.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 InstanceAttribute**, 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 attributedObject = new object();
attach new InstanceAttribute() to attributedObject;

The problem is locating and dealing with attributes. There would have to bea class that does attaching, detaching, and lookups, something in
System.Reflection, 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(first 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(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 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\privledged 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 InstanceAttributeAcl(typeof(MyClass),Actions.Attac h |
Actions.Detach | Actions.Read) to myRestrictedInstance;

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

[Frans Bouma]

(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(){return 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.WriteLine(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(){return new Foo();}

public void CalculateNewValue()
{
m_value = Bar.NewRandomValue() * 10;
}

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

Now, CalculateNewValue 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 CalculateNewValue() 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 misunderstanding, ignore my posting :))

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

FB

[Magnus Lidbom]

On Thu, 05 Feb 2004 02:27:43 -0800, Frans Bouma
<pe******************@xs4all.nl> 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(){return 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.WriteLine(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(){return new Foo();}

public void CalculateNewValue()
{
m_value = Bar.NewRandomValue() * 10;
}

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

Now, CalculateNewValue 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 CalculateNewValue 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 CalculateNewValue() 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 misunderstanding, 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 CalculateNewValue() is violating the
contract in a non-const support language, the compiler has to examine
CalculateNewValue(),

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

[Frans Bouma]

Magnus Lidbom <ma***********@hotmail.com> wrote in
news:nt********************************@4ax.com:

On Thu, 05 Feb 2004 02:27:43 -0800, Frans Bouma
<pe******************@xs4all.nl> 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(){return new Foo();}

public void CalculateNewValue()
{
m_value = Bar.NewRandomValue() * 10;
}

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

Now, CalculateNewValue 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 CalculateNewValue 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 CalculateNewValue, 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

[Magnus Lidbom]

On Thu, 05 Feb 2004 10:24:15 -0800, Frans Bouma
<pe******************@xs4all.nl> 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.nl> 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