"Extension" properties?

  • Thread starter Thread starter Arthur Dent
  • Start date Start date
Jon Skeet said:
I personally see nothing wrong with a thread which happens to only
include MVPs. Any non-MVP could jump in at any time, no problem.

However, I'm pretty sure Bill and I will never see eye to eye on this,
and I don't think further discussion will actually help. That's why I'm
not replying to the posts any further - I'm afraid I don't have any
more time to waste on a discussion which isn't really going anywhere.
Click to expand...

Thaks Jon. I enjoyed the discussion. I think it was eye opening. I think we
will disagree about what makes for a fluent interface, more than the issue
of extension properties themselves.
 
Bill McCarthy said:
Thaks Jon. I enjoyed the discussion. I think it was eye opening. I think we
will disagree about what makes for a fluent interface, more than the issue
of extension properties themselves.
Click to expand...

That and what counts as underlying storage ;)

Hope you don't mind me ducking out of the discussion. Let's save the
time for another one in the near future!
 
Bill McCarthy said:
Isn't that more to do with mixins ?
Click to expand...

I don't know if it's called mixin.

It's just an extension of an existing type by methods and properties, which
can have state. A code sample similar to the sample shown by Amanda Silver:

\\\
Public Class Foo
Extends Goo

Private m_Bla As Integer

Public Property Bla() As Integer
Get
Return m_Bla
End Get
Set(ByVal Value As Integer)
m_Bla = Value
End Set
End Property
End Class
///

This can even be used to extend 'NonInheritable' types.
 
Hi Herfried,

Herfried K. Wagner said:
I don't know if it's called mixin.

It's just an extension of an existing type by methods and properties,
which can have state. A code sample similar to the sample shown by Amanda
Silver:

\\\
Public Class Foo
Extends Goo

Private m_Bla As Integer

Public Property Bla() As Integer
Get
Return m_Bla
End Get
Set(ByVal Value As Integer)
m_Bla = Value
End Set
End Property
End Class
///

This can even be used to extend 'NonInheritable' types.
Click to expand...


My *guess* is that is as a mixin. An instance of Foo would not be an
instance of Goo, but Foo would implement any interfaces Goo does, and
probably implicitly expose any members that Goo would. The problem is when
there is a naming clash you need a more explicit syntax or a renaming
scheme. For example, let's say you want to extend a Goo and a Bar, but they
both have a Name property. For .NET the only way around that would be you'd
have to have an explicit way of calling the member of Foo versus the one on
Bar. One solution might be to expose readonly Goo and Bar properties, or
alternatively create interfaces for the type Goo and Bar and require access
via the interface. Neither of those approaches however really make the
methods of Goo and Bar *directly* accessible as part of Foo. Perhaps the
solution is for the IDE to warn when there is a naming clash, and you could
click on the warning and choose to implement the methods that clash.
 
Bill,

Bill McCarthy said:
My *guess* is that is as a mixin. An instance of Foo would not be an
instance of Goo, but Foo would implement any interfaces Goo does, and
probably implicitly expose any members that Goo would. The problem is
when
there is a naming clash you need a more explicit syntax or a renaming
scheme. For example, let's say you want to extend a Goo and a Bar, but
they both have a Name property.
Click to expand...

I didn't event think of the possibility to be able to specify more than once
type in the 'Extends' statement. If it would be only possible to specify a
single type, no name clashes can occur (except between members introduced in
'Foo' and members of 'Goo'). Am I missing something?
 
Herfried K. Wagner said:
Bill,



I didn't event think of the possibility to be able to specify more than
once type in the 'Extends' statement. If it would be only possible to
specify a single type, no name clashes can occur (except between members
introduced in 'Foo' and members of 'Goo'). Am I missing something?
Click to expand...

If it is only single extends, you would still have issues with naming
clashes and your classes base classes potentially. If it is *only* single
extends and no base classes then I think the syntax is pretty much a waste.
You wouldn't be inheriting, there'd be no overrides, etc. If it is single
only, I think spending that time on reevaluating what classes are sealed and
what are not would be far more appropriate. Seems a real shame... I was
hoping we were getting mixins.
 
Actually, it might not be so hard really.

As it is, with extension methods, the "extending" programmer is responsible
for providing the implementation of the method.
The same could be said for extension properties, that the programmer is
responsible for providing the storage implementation.

Some objects would very readily lend themselves to this, others the
programmer might actually have to use their own storage medium.

For example, say I wanted to extend the HttpSessionState class, adding a
LastException property.
(Yes, I know about Server.GetLastError, but that resets after any following
lines of code execute.)

I could code this extension as so...

<Extension> Public Property LastException(target As HttpSessionState) As
Exception
Get
Return target("lastExceptionHandle")
End Get
Set (value As Exception)
target("lastExceptionHandle") = value
End Set
End Property
 
There's so much stuff here in this post that (at my first glance) doesn't seem to address what I would like to do...

I would like to write the most basic of extension "properties" that returned the number of items in ANY generic enumeration.

For example:

public IEnumerable<int> GetFilteredInts( int p_min )
{
for (int i = 0; i < 100; i++)
if (i <= p_min)
yield return i;
}


THEN... in some library, to write a (seemingly fictional) "extension property" called "Count" that looks like: (equally fictional, i get it!)

public static class Class_I_Wish<T>
{
public static int Count(this IEnumerable<T> grrrrrr)
{
get
{
int count=0;
foreach( T obj in grrrrrr )
count++;
return count;
}
}
}

Now, don't get me wrong- I HAVE solved the problem from a functional level, but it does not have the aesthetic qualities that an "extension property" would have.

I know that I'm not going to get anything actually implemented by posting here, but I would love to hear from others regarding this particular example and whether or not I should try to further my crusade into Microsoft itself.

Cheers!
-- mike
 
Back
Top