how to avoid inlining?

  • Thread starter Thread starter Lloyd Dupont
  • Start date Start date
Jon Skeet said:
Yes, you need to suppress inlining - but more importantly, you need the
reference to be marshalled rather than the value. Surely *that* is the
primary purpose of the type.
Click to expand...
Again it comes down to context. If your context is I have an object and I
need to marshall it across an appdomain, then you will think that is the
primary purpose of the type. If your context is how that architecture works
then you will think in terms of why that class is there in that context.

Regards
Kjetil Kristoffer Solberg
 
I think it's much more simple.
MarshalByRef subclass's method might not be implemented at all, but this is
an unintended side effect.
Something that cannot be relied on because it might change without notice.

If you use it for this purpose your code might break again in the future,
for some 'apparently mysterious' reason.... (i.e. upgrading to .NET
4/5/6/other...)

Whereas with the attribute: this is the purpose of it and won't be changed.



--
Regards,
Lloyd Dupont
NovaMind Software
Mind Mapping at its best
www.nova-mind.com
 
Kjetil said:
Again it comes down to context. If your context is I have an object and I
need to marshall it across an appdomain, then you will think that is the
primary purpose of the type. If your context is how that architecture works
then you will think in terms of why that class is there in that context.
Click to expand...

I don't think that really makes sense as a way of thinking about the
primary purpose of a type. "How it works" (i.e. the implementation)
isn't the *reason* for a type existing.

Surely a good test for the primary purpose of a type is to see whether
or not it would still be worth having if that purpose weren't required.
Let's test that theory:

Suppose marshalling by reference didn't require inlining to be avoided
- for example if the CLR didn't do any inlining anyway. Would
MarshalByRefObject still be worth having? Absolutely. Admittedly in
this case it could be replaced by an attribute, potentially, as
described in
http://blogs.thinktecture.com/ingo/archive/2003/01/24/413866.aspx
You'd still need something to indicate that you wanted marshalling by
reference though, and deriving from MarshalByRefObject is currently
*the* way of doing that.


Now suppose instead that no-one ever needed to marshal by reference,
but occasionally did want to prevent inlining. Would MarshalByRefObject
still be worth having? Nope - MethodImplOptions already has that
functionality.



For these reasons, I still think it makes little sense to claim that
the primary purpose of the MarshalByRefObject type is to prevent
inlining. That may well be a very important part of its implementation,
but that's not the same thing at all.
 
Jon Skeet said:
I don't think that really makes sense as a way of thinking about the
primary purpose of a type. "How it works" (i.e. the implementation)
isn't the *reason* for a type existing.
Click to expand...
If the transparent proxy can be bypassed by inlining then there would be no
way for this communications architecture to work. Don't you think ensuring
this architecture works is the primary purpose behind MarshalByRefObject?
Surely a good test for the primary purpose of a type is to see whether
or not it would still be worth having if that purpose weren't required.
Let's test that theory:

Suppose marshalling by reference didn't require inlining to be avoided
- for example if the CLR didn't do any inlining anyway. Would
MarshalByRefObject still be worth having? Absolutely. Admittedly in
this case it could be replaced by an attribute, potentially, as
described in
http://blogs.thinktecture.com/ingo/archive/2003/01/24/413866.aspx
You'd still need something to indicate that you wanted marshalling by
reference though, and deriving from MarshalByRefObject is currently
*the* way of doing that.
Click to expand...
Please lets argue based on the facts.
Now suppose instead that no-one ever needed to marshal by reference,
but occasionally did want to prevent inlining. Would MarshalByRefObject
still be worth having? Nope - MethodImplOptions already has that
functionality.
Click to expand...
The problem with MethodImplOptions is that anyone relying on all the methods
of a class to be inlined is now dependent upon the developer of the type to
actually set this attribute on all the methods. A descent architecture in my
opinion should not be dependent in this way upon the individual programmer.
MarshalByRefObject solves this problem and as such still worth having.
For these reasons, I still think it makes little sense to claim that
the primary purpose of the MarshalByRefObject type is to prevent
inlining. That may well be a very important part of its implementation,
but that's not the same thing at all.
Click to expand...
I disagree. The most important reason behind MarshalByRefObject is
suppression of inlining. Lifetime management is also important but
secondary.


Regards
Kjetil Kristoffer Solberg
 
KKS said:
The problem with MethodImplOptions is that anyone relying on all the
methods of a class to be inlined is now dependent upon the developer of
the type to actually set this attribute on all the methods. A descent
architecture in my opinion should not be dependent in this way upon the
individual programmer. MarshalByRefObject solves this problem and as such
still worth having.
Click to expand...
This should read like this:

The problem with MethodImplOptions is that anyone relying on all the methods
of a class *not* to be inlined is now dependent upon the developer of the
type to
actually set this attribute on all the methods. A descent architecture in
my
opinion should not be dependent in this way upon the individual programmer.
MarshalByRefObject solves this problem and as such still worth having.


Sorry for the typo.

Regards
Kjetil Kristoffer Solberg
 
If the transparent proxy can be bypassed by inlining then there would be no
way for this communications architecture to work. Don't you think ensuring
this architecture works is the primary purpose behind MarshalByRefObject?
Click to expand...

Making sure that the architecture works is what MarshalByRefObject has
to do in order to fulfil its primary purpose of making it possible to
marshal objects by reference
Please lets argue based on the facts.
Click to expand...

What exactly are you taking issue with? I don't see what's wrong with
considering a hypothetical situation.
The problem with MethodImplOptions is that anyone relying on all the methods
of a class to be inlined is now dependent upon the developer of the type to
actually set this attribute on all the methods. A descent architecture in my
opinion should not be dependent in this way upon the individual programmer.
MarshalByRefObject solves this problem and as such still worth having.
Click to expand...

If preventing inlining weren't necessary for marshalling by reference,
can you think of any other examples where you would really want to
prevent *all* methods in a type from being inlined?
I disagree. The most important reason behind MarshalByRefObject is
suppression of inlining. Lifetime management is also important but
secondary.
Click to expand...

The most important *implementation detail* of MarshalByRefObject may
well be suppression of inlining, but that's not the same as it being
the reason it exists in the first place.
 
Back
Top