| Groups | Blog | Home |
vb.net : "Extension" properties?
attribute with class *Properties*? Internally properties are just implemented as a pair of functions (get/set), aren't they? So shouldn't it be possible to create Extension Properties? Thanks in advance, - Arthur Dent.
[quoted text, click to view]
Arthur Dent <hitchhikersguideto-news@yahoo.com> wrote: > Hi all, ... is there any way to use the new CompilerServices Extension > attribute with class *Properties*? Not at the moment. [quoted text, click to view] > Internally properties are just implemented as a pair of functions (get/set), > aren't they? So shouldn't it be possible to create Extension Properties? Properties are more than just a pair of functions - they're metadata associated with the property itself. Basically extension properties aren't supported yet - at least not in C#. That's not to say that'll be the case forever, but for the moment we've only got extension methods. -- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
[quoted text, click to view]
On Jan 29, 10:22 am, "Bill McCarthy" <B...@NOSPAM.com> wrote: <snip> [quoted text, click to view] > > but a lot of times extension > > properties would be useful even if they weren't able to store extra > > state. > > Well then it is a method not a property really. A property should be > similar to a field. What gives you that impression? Consider DateTime - all the properties there are calculations based off a single field. There are plenty of times when several properties can be calculated from a single field - or where a particular type will override a property to always return the same value. The whole point of a property (as opposed to a field) is to allow the implementation to do more than it would with a field. It could do lazy loading from a database, for instance. The API is specified only in terms of what the client can expect to be returned/set, not how that is implemented. [quoted text, click to view] > > Often they could calculate the value given the existing state. > > Sure, but why use a property there when they can use a method ? A method is > actually more flexible as you can set a value as well as return a value with > the one method. Would you really suggest that all the DateTime properties should be methods? [quoted text, click to view] > > Extension properties would also be very useful for writing fluent > > interfaces. > > Really ? How so ? You can't set a value and return a value with a > property. Um, you don't tend to do that with fluent interfaces. Having extension properties would mean being able to write: var x = 2.Dollars; instead of var x = 2.Dollars(); for instance, or var meetingTime = 2.Days.From.Now; which reads somewhat better than: var meetingTime = 2.Days().From().Now();
[quoted text, click to view]
On Jan 29, 11:41 am, "Bill McCarthy" <B...@NOSPAM.com> wrote: > > Would you really suggest that all the DateTime properties should be > > methods? > > They are all read only properties so there is no benifit compared to a > method call. The benefit is in readability. I wouldn't expect to see many writable extension properties, but read-only ones would be useful. [quoted text, click to view] > >> > Extension properties would also be very useful for writing fluent > >> > interfaces. > > >> Really ? How so ? You can't set a value and return a value with a > >> property. > > > Um, you don't tend to do that with fluent interfaces. > > Since when ? Here, read Martin Fowler on them:http://martinfowler.com/bliki/FluentInterface.html Okay, "don't tend to" was a bad choice of words. Let me rephrase: there are plenty of situations using fluent interfaces where you don't need to pass any parameters, at which point extension properties make life more readable. [quoted text, click to view] > To claim that fluent interfaces are only read only properties is complete > nonsense. The whole idea is you can set,fecth, calculate and read in a > chained statement. The idea is that you can build what you need to build in the most readable form. [quoted text, click to view] > > Having extension properties would mean being able to write: > > > var x = 2.Dollars; > > > instead of > > > var x = 2.Dollars(); > > So that'd be a C# language issue requiring ()'s on methods not properties. Well, I'd argue that's a VB issue of hiding the difference between methods and properties, but a C# issue of not supporting extension properties. [quoted text, click to view] > > for instance, or > > > var meetingTime = 2.Days.From.Now; > > which reads somewhat better than: > > var meetingTime = 2.Days().From().Now(); > > Again, an issue in C#, not VB ;) Sure. It still means that extension properties are desirable as far as I'm concerned.
[quoted text, click to view]
On Jan 29, 12:44 pm, "Bill McCarthy" <B...@NOSPAM.com> wrote: > > The benefit is in readability. I wouldn't expect to see many writable > > extension properties, but read-only ones would be useful. > > Again, there is no readability difference for a method compared to a > ReadOnly property, at least not in VB. Sure - that doesn't stop them being useful in C# though. [quoted text, click to view] > >> > Um, you don't tend to do that with fluent interfaces. > > >> Since when ? Here, read Martin Fowler on > >> them:http://martinfowler.com/bliki/FluentInterface.html > > > Okay, "don't tend to" was a bad choice of words. Let me rephrase: > > there are plenty of situations using fluent interfaces where you don't > > need to pass any parameters, at which point extension properties make > > life more readable. > > Let me quote to you what Martin Fowler says: > <quote> > The common convention in the curly brace world is that modifier methods are > void, which I like because it follows the principle of > CommandQuerySeparation. This convention does get in the way of a fluent > interface, so I'm inclined to suspend the convention for this case. > </quote> > > So clearly, Martin is saying that "Properties" as used in C style languages > such as C#, does get in the way of a fluent interface. Well, I disagree for at least *some* fluent interfaces - because I'd prefer to make the methods return new values based on the old rather than changing the existing value. This is the way that LINQ works, for example - you chain together many sequences, rather than changing the existing one. Other fluent interfaces such as StringBuilder return "this" at the end of modifying methods like Append, but I certainly wouldn't use an extension property to do that kind of thing. Ick! In general I prefer immutable types where they're reasonable, and fluent interfaces work very well with that pattern. [quoted text, click to view] > >> To claim that fluent interfaces are only read only properties is complete > >> nonsense. The whole idea is you can set,fecth, calculate and read in a > >> chained statement. > > > The idea is that you can build what you need to build in the most > > readable form. > > Again, and extension method provides the same readability. If I read you > right, the issue you have is with having to have the ()'s. Well don't you > want them there considering with extension methods, and also properties, you > can get a null reference exception for the object being extended... > something you should never be able to get with properties ;) I don't see what bearing NullReferenceExceptions have on the matter at all. Where's the connection between them and brackets? And yes, it's a case of getting rid of the extra parentheses in *some* cases. [quoted text, click to view] > >> So that'd be a C# language issue requiring ()'s on methods not > >> properties. > > > Well, I'd argue that's a VB issue of hiding the difference between > > methods and properties, but a C# issue of not supporting extension > > properties. > > VB gives you the choice. C# seems to be forcing you to write things you say > are less readable ;) In this particular case, yes. It's a very specific case, however, and in general I'm in favour of C#'s strictness here. [quoted text, click to view] > >> Again, an issue in C#, not VB ;) > > > Sure. It still means that extension properties are desirable as far as > > I'm concerned. > > Or make the ()'s optional when calling extension methods. Ick - I'd very much *not* be in favour of that. Having extension properties (and potentially even operators) is a much cleaner and more consistent solution.
[quoted text, click to view]
On Jan 29, 2:05 pm, "Bill McCarthy" <B...@NOSPAM.com> wrote: > >> Again, there is no readability difference for a method compared to a > >> ReadOnly property, at least not in VB. > > > Sure - that doesn't stop them being useful in C# though. > > Well if this isn't an issue for Vb, yet it is an issue for C#, then perhaps > C# should be looking at what VB does already today. I believe it should be looking at a mechanism which fits in with everything that exists today. Extension properties are a natural extension of where we are today - making brackets optional isn't. [quoted text, click to view] > >> So clearly, Martin is saying that "Properties" as used in C style > >> languages > >> such as C#, does get in the way of a fluent interface. > > > Well, I disagree for at least *some* fluent interfaces - because I'd > > prefer to make the methods return new values based on the old rather > > than changing the existing value. > > You are talking read only properties; Martin is talking about richer fluency > including creation. The properties can create objects with no problems. I don't see what your objection is here. [quoted text, click to view] > Just how big is the need for ReadOnly extension properties on immutable > types ? I think in virtually all cases you think of, you'll find that you > actually start needing to define the types, and hence can place real > properties in them. Various options with dates and times, numbers etc. Put it this way: I've encountered cases where I'd like to use them, and others have too (if you search for "extension properties" you'll find others who wish to use them for fluent interfaces). [quoted text, click to view] > > This is the way that LINQ works, for > > example - you chain together many sequences, rather than changing the > > existing one. > > LINQ works as extension methods, e.g Count or Sum. Yes, but the point is that those extension methods aren't modifier methods - they don't change the object they appear to be called on, they merely return a new one. This isn't the same as the StringBuilder.Append type behaviour, which is what I believe Martin was talking about in the quote that you mentioned. [quoted text, click to view] > > Other fluent interfaces such as StringBuilder return "this" at the end > > of modifying methods like Append, but I certainly wouldn't use an > > extension property to do that kind of thing. Ick! In general I prefer > > immutable types where they're reasonable, and fluent interfaces work > > very well with that pattern. > > So you want extension properties only for immutable types and (hence) only > ReadOnly properties ? This all for the sake of ommitting the ()'s right ? Primarily, not necessarily "only". I certainly don't imagine that I can foresee all possible uses. [quoted text, click to view] > > I don't see what bearing NullReferenceExceptions have on the matter at > > all. Where's the connection between them and brackets? > > An extension method or property (if they were to exist) can be passed a null > reference as the object they are extending. Yes, I'm aware of that. [quoted text, click to view] > Since when does it make sense > that a null object has properties and that the property getter (or setter) > would get called ?? I'd guess in a similar set of situations to where it makes sense to call a method on a null object. Where do you see the difference between methods and properties here? [quoted text, click to view] > > And yes, it's a case of getting rid of the extra parentheses in *some* > > cases. > > Well that's the only reason so far, and so far you've also limited it to > ReadOnly and immutable types. In the cases I've wanted to use, yes. [quoted text, click to view] > > In this particular case, yes. It's a very specific case, however, and > > in general I'm in favour of C#'s strictness here. > > Why ? A property is just a wrapper for a setter and getter. Yes, but I believe it's good to know that that's what you're using, rather than calling a method. But hey, that's part of the C# philosophy. [quoted text, click to view] > >> Or make the ()'s optional when calling extension methods. > > > Ick - I'd very much *not* be in favour of that. Having extension > > properties (and potentially even operators) is a much cleaner and more > > consistent solution. > > Cleaner ? You'd be adding properties that don't exist. In exactly the same way as methods are added which don't exist. [quoted text, click to view] > If you serialize a > type then deserialize it, it doesn't have the same properties. The extension property values wouldn't be serialized, but that should be fine because their values should only depend on *other* state. Consider serialization as storing state, and we can't add state with extension methods or properties. [quoted text, click to view] > That should > be enough to say it isn't clean, it's a poor fudge pretending a type has > properties when it does not. Do you object to extension methods as well? [quoted text, click to view] > If you look at all the issues associated with > extension properties, it becomes clear they aren't clean. Which issues? Where are they problematic in places that extension methods aren't? [quoted text, click to view] > You have already > said you'd basically only use them for ReadOnly properties, and only on > immutable types. Probably. That doesn't mean there aren't other uses - but those would be the majority, I imagine. [quoted text, click to view] > This just to avoid having ()'s seems to be polluting the > language if you ask me. And you need to consider the effect that then has > on the CLR and cross language interoperability. Take all these things and > weigh them up against having to add ()'s Why would it have *any* effect on the CLR? Extension methods don't have any effect on the CLR, so why should extension properties? It's all just a compile-time bit of syntactic sugar. Heck, C# could even gain extension properties without VB understanding of being able to generate them...
[quoted text, click to view]
Bill McCarthy <Bill@NOSPAM.com> wrote: > The problem is more complex than it might first seem. A property represents > a "state" of an object, whereas methods typically indicate something is > fetched or calculated. So for extension properties you would need a state > store that is associated with an instance. Sure you could do this with a > static (Shared) dictionary of some sort, but you'd also need to ensure you > use weak references so as you don't inadvertently keep the objects alive. No, that would be a bad thing to do - but a lot of times extension properties would be useful even if they weren't able to store extra state. Often they could calculate the value given the existing state. Extension properties would also be very useful for writing fluent interfaces. -- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
[quoted text, click to view]
On Jan 29, 3:31 pm, "Bill McCarthy" <B...@NOSPAM.com> wrote: > > Amanda Silver of the VB team presented an 'Extends' statement in her talk > > about VB's future on TechEd EMEA 2007 which served exactly this purpose: > > Extension of existing types with support extra state. This concept goes > > far beyond extension methods, which are only syntactic sugar. > > Isn't that more to do with mixins ? Certainly sounds like it - different kettle of fish entirely. (And one with significant limitations or issues, depending on what's being proposed. I love the idea of mixins in an appropriate way, and particularly for interfaces which just delegate to another implementation, but I think we need to be wary of going too far.)
[quoted text, click to view]
On Jan 29, 3:55 pm, "Bill McCarthy" <B...@NOSPAM.com> wrote: > > I believe it should be looking at a mechanism which fits in with > > everything that exists today. Extension properties are a natural > > extension of where we are today - making brackets optional isn't. > > No extension properties are not a natural extension for C#. In fact they go > against the C# rule of not allowing parameters to property gets *except* in > the case of indexers, in which case you are required ot use [] and the > property name Item is hidden. But at the point of *use* they don't take a parameter - they act on an instance. [quoted text, click to view] > >> You are talking read only properties; Martin is talking about richer > >> fluency > >> including creation. > > > The properties can create objects with no problems. I don't see what > > your objection is here. > > You're kidding me right ? The ReadOnly properties can only create a very > narrow predefined set of objects based on the public exposed state of the > object being extended. You certainly could not be adding line items to a > record. Who said I'd be adding line items to a record? The example Martin happens to give isn't the only use of fluent interfaces. In many cases the publicly exposed state is more than enough to get to the next value. [quoted text, click to view] > >> Just how big is the need for ReadOnly extension properties on immutable > >> types ? I think in virtually all cases you think of, you'll find that > >> you > >> actually start needing to define the types, and hence can place real > >> properties in them. > > > Various options with dates and times, numbers etc. > > None that require properties though ;) Nothing *requires* properties, but that doesn't mean there isn't an appeal to them. Extension methods aren't *required* but they make code easier to read. [quoted text, click to view] > > Put it this way: I've encountered cases where I'd like to use them, > > and others have too (if you search for "extension properties" you'll > > find others who wish to use them for fluent interfaces). > > Well I haven't seen them. I thought if it was a major issue they'd be well > known and well described. If you wish to present soem examples, that'd be > good, it may even further the conversation. As I suggested, search for them. A search for "extension properties" "fluent interfaces" gets interesting hits from people such as Scott Guthrie. For instance, from: http://weblogs.asp.net/scottgu/archive/2007/03/13/new-orcas-language-feature-extension-methods.aspx <quote> Right now we don't support extension properties. It is something I know the language teams are considering for the future - but for right now you can only add methods. </quote> So it sounds like it's not exactly far-fetched. [quoted text, click to view] > > Yes, but the point is that those extension methods aren't modifier > > methods - they don't change the object they appear to be called on, > > they merely return a new one. This isn't the same as the > > StringBuilder.Append type behaviour, which is what I believe Martin > > was talking about in the quote that you mentioned. > > I was commenting about your statement in regards to LINQ not in regards to > Martin's statements, so that wasn't the point at all ;) > > Martin was talking about rich fluent interfaces, something which extension > properties in C# would NOT provide. They would make various situations more readable than they are now. Martin was talking about modifier methods, which are useful in some cases but not all. I wouldn't use a property in such cases - but that doesn't mean there's no value in them. [quoted text, click to view] > >> So you want extension properties only for immutable types and (hence) > >> only > >> ReadOnly properties ? This all for the sake of ommitting the ()'s right > >> ? > > > Primarily, not necessarily "only". I certainly don't imagine that I > > can foresee all possible uses. > > Extension properties with setters raise a whole heap of issues. It really > is important to step back and look at basic OO principles. They aren't > properties of the object and they could only manipulate existing public > properties. It's fundamentally wrong to present them as properties. Not necessarily. Suppose something had a Size property, but you only wanted to change the Width. That ends up being: foo.Size = new Size (newWidth, foo.Size.Height); You could easily encapsulate that in extension properties for Height and Width. Are there potential issues with properties not being orthogonal? Sometimes - but sometimes it makes life easier, too. [quoted text, click to view] > >> An extension method or property (if they were to exist) can be passed a > >> null > >> reference as the object they are extending. > > > Yes, I'm aware of that. > > So you think a null reference should have properties ? If it can have methods, I don't see why it shouldn't have properties. As you keep pointing out, properties are just wrappers for methods. What makes it okay for extension methods but not for extension properties? [quoted text, click to view] > >> Since when does it make sense > >> that a null object has properties and that the property getter (or > >> setter) > >> would get called ?? > > > I'd guess in a similar set of situations to where it makes sense to > > call a method on a null object. Where do you see the difference > > between methods and properties here? > > OO 101 ;) A method is not claiming to be a property of a non existant > object. No, it's claiming to be a method acting on a non-existent object. I don't see why that's any better or worse. [quoted text, click to view] > >> > And yes, it's a case of getting rid of the extra parentheses in *some* > >> > cases. > > >> Well that's the only reason so far, and so far you've also limited it to > >> ReadOnly and immutable types. > > > In the cases I've wanted to use, yes. > > >> > In this particular case, yes. It's a very specific case, however, and > >> > in general I'm in favour of C#'s strictness here. > > >> Why ? A property is just a wrapper for a setter and getter. > > > Yes, but I believe it's good to know that that's what you're using, > > rather than calling a method. > > > But hey, that's part of the C# philosophy. > > ROFL, now I know you are kidding me. C# hides indexers from you guys > because they don't want you to create properties that take parameters. > Go-on, have a look at what get's compiled and call it from IL ;) I don't need to - I'm not exactly a C# newbie. But generally, C# doesn't give you the sort of ambiguity which VB allows. For instance, you can't do this from C#, thank goodness: Thread t = new Thread(...); t.Sleep(1000); You can in VB, although I understand it was made an optional warning/ error in VB8. [quoted text, click to view] > >> Cleaner ? You'd be adding properties that don't exist. > > > In exactly the same way as methods are added which don't exist. > > They aren't claiming to be **properties**.
[quoted text, click to view]
On Jan 29, 4:52 pm, "Bill McCarthy" <B...@NOSPAM.com> wrote: <snip> [quoted text, click to view] > > Not necessarily. Suppose something had a Size property, but you only > > wanted to change the Width. That ends up being: > > > foo.Size = new Size (newWidth, foo.Size.Height); > > > You could easily encapsulate that in extension properties for Height > > and Width. Are there potential issues with properties not being > > orthogonal? Sometimes - but sometimes it makes life easier, too. > > Okay so let me call you out on this example. show *exactly* how extension > properties would solve that and make it easier. Setting the Height property would actually set the Size property with a copy of the existing Size value, but with the new height. Setting the Width property would actually set the Size property with a copy of the existing Size value, but with the new width. Calling code which previously had to be: foo.Size = new Size(newWidth, foo.Size.Height); would then be foo.Width = newWidth; I know which I prefer to read :) The same is true when I'm only interested in reading the height: Old: Console.WriteLine (foo.Size.Height); New: Console.WriteLine (foo.Height); Again, it's that little bit easier to read (IMO). Now, the disadvantage is that if people use both Width and Height when setting both, they get the right results but in an inefficient way.
Hi Arthur,
The problem is more complex than it might first seem. A property represents a "state" of an object, whereas methods typically indicate something is fetched or calculated. So for extension properties you would need a state store that is associated with an instance. Sure you could do this with a static (Shared) dictionary of some sort, but you'd also need to ensure you use weak references so as you don't inadvertently keep the objects alive. [quoted text, click to view] "Arthur Dent" <hitchhikersguideto-news@yahoo.com> wrote in message
news:C17B2611-50AA-4D4A-B8B2-D98F8E2A32BD@microsoft.com... > Hi all, ... is there any way to use the new CompilerServices Extension > attribute with class *Properties*? > > Internally properties are just implemented as a pair of functions > (get/set), aren't they? So shouldn't it be possible to create Extension > Properties? > > Thanks in advance, > - Arthur Dent.
"Jon Skeet [C# MVP]" <skeet@pobox.com> schrieb:
[quoted text, click to view] >> The problem is more complex than it might first seem. A property >> represents >> a "state" of an object, whereas methods typically indicate something is >> fetched or calculated. So for extension properties you would need a >> state >> store that is associated with an instance. Sure you could do this with a >> static (Shared) dictionary of some sort, but you'd also need to ensure >> you >> use weak references so as you don't inadvertently keep the objects alive. > > No, that would be a bad thing to do - but a lot of times extension > properties would be useful even if they weren't able to store extra > state. Often they could calculate the value given the existing state. Amanda Silver of the VB team presented an 'Extends' statement in her talk about VB's future on TechEd EMEA 2007 which served exactly this purpose: Extension of existing types with support extra state. This concept goes far beyond extension methods, which are only syntactic sugar. -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://dotnet.mvps.org/dotnet/faqs/>
[quoted text, click to view]
Bill McCarthy <Bill@NOSPAM.com> wrote: > > "Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message > news:6c9e08c8-7eb6-476c-89de-19ae80d31519@v4g2000hsf.googlegroups.com... > > > > Calling code which previously had to be: > > > > foo.Size = new Size(newWidth, foo.Size.Height); > > would then be > > foo.Width = newWidth; > > So that's not a fluent interface is it ? No, it's not - and I never claimed it to be. You wanted an example of how a property setter would work, and I told you - having said earlier that for fluent interfaces I'd probably only use readonly properties. You claimed that extension properties with setters raised "a whole heap of issues". I've given an example to the contrary. I never claimed it had anything to do with fluent interfaces, nor did I ever claim that fluent interfaces would be the only use for extension properties. [quoted text, click to view] > And the property is read/write, not > readonly on an immutable type. For a fluent interface, you'd need to use a > method wouldn't you ? such that you could write : > foo.SetWidth(newWidth) > which would return foo so as you could continue to set values. That's not a fluent interface in the first place though. The point wasn't to show a fluent interface - it was to show how a writable extension property can still make sense. -- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
[quoted text, click to view]
Bill McCarthy <Bill@NOSPAM.com> wrote: > > No, it's not - and I never claimed it to be. You wanted an example of > > how a property setter would work, and I told you - having said earlier > > that for fluent interfaces I'd probably only use readonly properties. > > ah my bad. I was expecting you to provide examples of the fluent interfaces > you were talking about that you did want you implement using extension > properties. I mistakenly took the only sample you provided as that. Well, I provided fluent interface examples earlier - 1.Day.From.Now etc. The Size example I provided was within the context of the point of the discussion about mutation. [quoted text, click to view] > > You claimed that extension properties with setters raised "a whole heap > > of issues". I've given an example to the contrary. I never claimed it > > had anything to do with fluent interfaces, nor did I ever claim that > > fluent interfaces would be the only use for extension properties. > > Well we can always find the few odd exceptions, but really how common are > these ? Typically any type that has a read/write Size property also has a > Height and Width property or doesn't for good reasons. Often, yes - but that just shows one example of how properties can relate to each other. It's a particularly clear one, but it's far from unheard of to use the same expression in multiple pieces of code when one can't change the original type. [quoted text, click to view] > >> And the property is read/write, not > >> readonly on an immutable type. For a fluent interface, you'd need to use > >> a > >> method wouldn't you ? such that you could write : > >> foo.SetWidth(newWidth) > >> which would return foo so as you could continue to set values. > > > > That's not a fluent interface in the first place though. > > Which, you're example or mine ? Mine is, as it is returning the type after > setting a value. It's not what I think of as fluent. It's not something that's likely to easily be built into a sort of sentence which is easily understandable. There's a certain amount of personal discretion on this kind of thing though :) [quoted text, click to view] > > The point > > wasn't to show a fluent interface - it was to show how a writable > > extension property can still make sense. > > Sure it can, but rarely. The underlying storage has to be exposed, and the > action you are doing has to be a subset of that. No, nothing about an extension property would expose or use the underlying storage. The implementer of the original type could still change the implementation of any methods/properties used without the extension property breaking. [quoted text, click to view] > That doesn't change the > fact that when there isn't already an exposed storage there's issues. What's the exposed storage with a Size property? Is it implemented as a Size instance inside the type, or as a pair of integers which is built into a size on demand? Who knows? It's an implementation detail which *isn't* exposed just because there's a Size property. [quoted text, click to view] > So I am still interested in the cases you say you would use extension > properties, in particular the fluent interfaces with them. The fluent interface side would be most relevant with a chain of no-parameter conversions - dates and times are the most obvious examples here. Beyond that I'd have to see where things lead - I'm certainly not claiming to be a DSL or fluent interface expert, but I've seen enough to be convinced that extension properties would be a welcome addition. -- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
[quoted text, click to view]
Bill McCarthy <Bill@NOSPAM.com> wrote: > > I don't need to - I'm not exactly a C# newbie. But generally, C# > > doesn't give you the sort of ambiguity which VB allows. For instance, > > you can't do this from C#, thank goodness: > > > > Thread t = new Thread(...); > > t.Sleep(1000); > > > > You can in VB, although I understand it was made an optional warning/ > > error in VB8. > > I missed this before. Yes as of VB 8 (aka 2005), IOW the last 3 years, it > has been a warning. Is it a warning by default? I can't remember now. I guess it might depend on whether or not the project is new or converted. [quoted text, click to view] > VB doesn't hide it from you. It certainly used to though. I'm glad it doesn't now, but it's still a good example of a choice where the benefits of providing choice are outweighed by the downsides. [quoted text, click to view] > What Vb does do is allow > you to choose to call a static method from an instant variable if you want > to. Can be quite handy as it means you can avoid repeating long type and > namespace declarations, although generally I would recommend it. If you *really* want to do that in C#, you can use a using directive to introduce an alias. I believe that's clearer in intent than using a variable to make a call to a static method which looks like an instance method. [quoted text, click to view] > The thing is, VB gives you the choice, just like the do with the ()'s > on a parameterless method call. And I believe some choices are not worth the problems they introduce. The thread example is a readability nightmare. It was a mistake to allow it in Java, and it was a mistake to allow it in VB, IMO. -- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
[quoted text, click to view]
Bill McCarthy <Bill@NOSPAM.com> wrote: > > Well, I provided fluent interface examples earlier - 1.Day.From.Now > > etc. > > So what exactly would From be in that example ? Probably an intermediate type which is only useful in conjunction with a following property. [quoted text, click to view] > Day would be a time span I presume That would be reasonable. [quoted text, click to view] > Now makes no sense as an extension as it wouldn't need any object to work > upon. And what if you wanted a day from any other date other than now ? > You write another extension for tomorrow, and another for > TheDayAfterTomorrow ? Well, the intermediate type could have Now, Yesterday, Tomorrow, Today and a few other properties as perfectly normal properties. The extension properties would be on Int32 and TimeSpan. [quoted text, click to view] > somehow I don't think 1.Day.From.Now is actually a practical example. Examples like that are reasonably common in the world of fluent interfaces - and you can't argue that the meaning isn't clear :) [quoted text, click to view] > > It's not what I think of as fluent. It's not something that's likely to > > easily be built into a sort of sentence which is easily understandable. > > There's a certain amount of personal discretion on this kind of thing > > though :) > > Well I could add a pointless Then extnesion that takes T and returns T then > it can be written as : > foo.SetWidth(100).Then.SetHeight(200) I wouldn't be suggesting that, certainly. [quoted text, click to view] > Personally I thinking adding extensions such as Then to make that supposedly > more fluent is actually the wrong idea of waht fluent interfaces is about. > It's not about trying to use english words. I think the example of your > 1.Day.From.Now when properly analyzed highlights that. Whereas I clearly think the reverse :) I think fluent interfaces have moved on from the original restrictive "always return the original context" sense, to mean a style of programming similar to a DSL, but within the syntax of an existing language. Mocking is a great example of fluent interfaces - many mocking APIs are designed with fluent interfaces so you can read a constraint out loud and get a good sense of what's being demanded. [quoted text, click to view] > >> > The point > >> > wasn't to show a fluent interface - it was to show how a writable > >> > extension property can still make sense. > >> > >> Sure it can, but rarely. The underlying storage has to be exposed, and > >> the > >> action you are doing has to be a subset of that. > > > > No, nothing about an extension property would expose or use the > > underlying storage. The implementer of the original type could still > > change the implementation of any methods/properties used without the > > extension property breaking. > > Okay we are talking about things from different perspectives here. I was > referring tothe extensions underlyiong storage has to be exposed by the type > it is extending. Clearer now ? Um, not really. Nothing has to reveal whether it's storing the data in a single field, combined fields, a database etc. That's what I consider to be "underlying storage". Yes, the original type has to expose the state in some form or other, but that's to be expected. When designing a type, you don't always know how people will use it - particularly if you're designing something like the .NET framework itself. Even if you knew what each different use would find beneficial you might not want to include it all - it could make the API horrific. However, for a particular use, it may well make sense to expose some state in a different form from the general purpose use. [quoted text, click to view] > >> That doesn't change the > >> fact that when there isn't already an exposed storage there's issues. > > > > What's the exposed storage with a Size property? Is it implemented as a > > Size instance inside the type, or as a pair of integers which is built > > into a size on demand? Who knows? It's an implementation detail which > > *isn't* exposed just because there's a Size property. > > You are focusing on the wrong message. What I was referring to is the Size > has to be exposed and the property you are exposing is merely a subset of > that. In practice I think this is pretty limited in value for property > sets. I think we probably differ in terms of our understanding of "underlying storage". [quoted text, click to view] > >> So I am still interested in the cases you say you would use extension > >> properties, in particular the fluent interfaces with them. > > > > The fluent interface side would be most relevant with a chain of > > no-parameter conversions - dates and times are the most obvious > > examples here. Beyond that I'd have to see where things lead - I'm > > certainly not claiming to be a DSL or fluent interface expert, but I've > > seen enough to be convinced that extension properties would be a > > welcome addition. > > I'm far from convinced. Seriously I am yet to see a real example. That > 1.Day.From.Now does not seem realistic at all to me. Why not? Do you never want to express that? Do you find it less readable than DateTime.Now.AddDays(1)? I know I prefer the fluent form - so what stops it from being realistic? -- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
[quoted text, click to view]
Bill McCarthy <Bill@NOSPAM.com> wrote: > > Is it a warning by default? I can't remember now. I guess it might > > depend on whether or not the project is new or converted. > > Not sure. I would presume so with Strict on semantics. > > >> VB doesn't hide it from you. > > > > It certainly used to though. I'm glad it doesn't now, but it's still a > > good example of a choice where the benefits of providing choice are > > outweighed by the downsides. > > Like extension properties when you have extension methods ;) Except I haven't seen any actual downsides being introduced by you. Yes, there'd need to be some extension to C# syntax, but that's about all I can think of. I don't see why it's conceptually such a problem. [quoted text, click to view] > > If you *really* want to do that in C#, you can use a using directive to > > introduce an alias. I believe that's clearer in intent than using a > > variable to make a call to a static method which looks like an instance > > method. > > Right you can alias in VB as well. But in both cases, Vb or C#, writing an > alias for a one of call is overkill really. Well yes - but it can be useful when you need to make a call repeatedly. Java has an interesting approach where you can import static members, so after something like (my Java is rusty) static import java.lang.Math.*; you can write double x = sqrt(PI*2); It's good when used *very sparingly*. [quoted text, click to view] > > The thread example is a readability nightmare. It was a mistake to > > allow it in Java, and it was a mistake to allow it in VB, IMO. > > > > That's one way of looking at it. Another is in the threading sample Sleep > as a static method was a bad name choice. It probably should have been > CurrentThreadSleep Nah, I don't buy it. When you make it clear that you're not calling it on a particular thread, the *only* thread that it could refer to is the current one. I wish Thread.CurrentThread were called Thread.Current though, and Thread.CurrentCulture were called Thread.Culture. It's a pain when you've got: Thread.CurrentThread.CurrentCulture ... Ick. I'd prefer: Thread.Current.Culture -- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
[quoted text, click to view]
Bill McCarthy <Bill@NOSPAM.com> wrote: > >> So what exactly would From be in that example ? > > > > Probably an intermediate type which is only useful in conjunction with > > a following property. > > Huh ? It does what exactly to the Day timespan value ? Remembers it. [quoted text, click to view] > So we can have: > > var x = 1.Day.From; > > then later someone writes: > > var dt = x.Now; > > looks very bad to me indeed. Patient: Doctor, it hurts when I do this (hits head) Doctor: Well don't do that then Seriously, fluent interfaces sometimes involve intermediate types which indeed don't make sense on their own, outside the fluent interface expression. [quoted text, click to view] > >> Day would be a time span I presume > > > > That would be reasonable. > > > >> Now makes no sense as an extension as it wouldn't need any object to work > >> upon. And what if you wanted a day from any other date other than now ? > >> You write another extension for tomorrow, and another for > >> TheDayAfterTomorrow ? > > > > Well, the intermediate type could have Now, Yesterday, Tomorrow, Today > > and a few other properties as perfectly normal properties. > > You still didn't answer as to what if you wanted a different date other than > those limited selection ? It falls down pretty quickly really. > And what exactly is Today compared to now when on a From return type ? > Would 1.Day.From.Today be different from 1.Day.From.Now ? 1.Day.From.Today would be the next midnight. 1.Day.From.Now would be this time tomorrow. [quoted text, click to view] > >> somehow I don't think 1.Day.From.Now is actually a practical example. > > > > Examples like that are reasonably common in the world of fluent > > interfaces - and you can't argue that the meaning isn't clear :) > > Not that I've seen. You got any references/links ? In Groovy: http://developers.sun.com/learning/javaoneonline/2007/pdf/TS-1589.pdf http://groovy.codehaus.org/Google+Data+Support C# 3 acting like Ruby: http://blog.troyd.net/PermaLink,guid,c4d8233b-77f4-4660-91a9- 8ea71cd358c7.aspx [quoted text, click to view] > I would have expected at best 1.Day.FromNow and 1.Day.BeforeNow Can't say I like those much personally, although the Sun/Thoughtworks paper uses something similar. [quoted text, click to view] > >> Well I could add a pointless Then extnesion that takes T and returns T > >> then > >> it can be written as : > >> foo.SetWidth(100).Then.SetHeight(200) > > > > I wouldn't be suggesting that, certainly. > > LOL. Yet you were happy with From that did nothing. Strange. True. I wouldn't like to say exactly why, but it's just a gut feeling. <snip> [quoted text, click to view] > > I think fluent interfaces have moved on from the original restrictive > > "always return the original context" sense, to mean a style of > > programming similar to a DSL, but within the syntax of an existing > > language. > > In the case of setting properties you return the original item. Likewise > when you add an item, you usually return the added item. The added item, or the collection it's been added to? The latter allows: x.Add(new Foo()) .Add(new Bar()) .Add(...) [quoted text, click to view] > So for the example > of SetWidth, you could potentially return a boolean, the width or the item. > Returning the item is the less restrictive and hence the most fluent > approach. I see your point there. An alternative in the world of immutable objects would be to return a new object equal to the previous one except with a different width. [quoted text, click to view] > > Mocking is a great example of fluent interfaces - many mocking APIs are > > designed with fluent interfaces so you can read a constraint out loud > > and get a good sense of what's being demanded. > > Right and they'd typically be methods, right. In many cases, yes - but I can imagine cases where it would be reasonable to use properties instead. [quoted text, click to view] > > Um, not really. Nothing has to reveal whether it's storing the data in > > a single field, combined fields, a database etc. That's what I consider > > to be "underlying storage". Yes, the original type has to expose the > > state in some form or other, but that's to be expected. > > The underlying storage for a property is the storage mechanism (not > necessarily state) for that property is it not ? So the type you are > extending has to expose suitable storage for your extension property. No, I'd say it has to allow the state to be mutated appropriately. It doesn't have to expose the nature of the storage (field, database etc). [quoted text, click to view] > You seem to be twisting what I am saying and getting away from the point > which was when there isn't an exposed suitable storage on the underlying > type, then the extension property has some serious issues. I can't help it if my understanding of "underlying storage" appears to be radically different to yours :) [quoted text, click to view] > > When designing a type, you don't always know how people will use it - > > particularly if you're designing something like the .NET framework > > itself. Even if you knew what each different use would find beneficial > > you might not want to include it all - it could make the API horrific. > > However, for a particular use, it may well make sense to expose some > > state in a different form from the general purpose use. > > I think that's very rare in reality. Again, I'm sure we'll have to agree to differ. (Is anyone else reading at this point?) [quoted text, click to view] > > I think we probably differ in terms of our understanding of "underlying > > storage". > > Clearly. You seem to view "underlying storage" as the backing fields when a > property is inside a type, yet for extension properties, you view it as the > private fields the extension couldn't get to. That doesn't make sense ot > me. The underlying storage for a property is where it writes and reads > from. Okay, using your definition the underlying storage of the original exposed property is the field (or whatever) then, right? I claim that you can write an extension property without knowing or caring that the original type happens to use a field. The original type doesn't need to expose its underlying storage - it needs to expose a storage interface, whether that's through properties or methods. [quoted text, click to view] > > Why not? Do you never want to express that? Do you find it less > > readable than DateTime.Now.AddDays(1)? I know I prefer the fluent form > > - so what stops it from being realistic? > > First and foremost I would typically have a date to which I want to add one > day. 1.Day.From.Now isn't going to help when I want to do a variable date > is it ? Like 1 day before your birthday. It becomes too limited, and as > such ends up creating more duplication, and hence more code maintenance. > Why would I want to take on the bloat and maintenance issues, when elsewhere > I am still going to be writing customer.Birthday.AddDays(-1) Where you've got a particular date, certainly use that date. <shrugs>
[quoted text, click to view]
Bill McCarthy <Bill@NOSPAM.com> wrote: > > Except I haven't seen any actual downsides being introduced by you. > > Yes, there'd need to be some extension to C# syntax, but that's about > > all I can think of. I don't see why it's conceptually such a problem. > > Well I have listed them, so if you haven't seen them I can only suggest an > optometrist. The biggest single issue is they are not properties of the > type. Every time you've listed them, I've indicated why I don't think they're relevant or downsides. <snip> [quoted text, click to view] > > Thread.CurrentThread.CurrentCulture ... > > > > Ick. I'd prefer: > > > > Thread.Current.Culture > > But hang on, didn't you just talk about aliases and type imports. Surely in > that light you can see the need for clear names on static methods ?? Aliases should only be used when they don't obscure the meaning. Who's going to alias Thread, after all? Would you say that String.Join() should be called String.JoinStrings() just in case someone creates an alias which makes it sound like it's joining together something completely different? -- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
Hi Jon,
[quoted text, click to view] "Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message news:MPG.2208e5641f27ba9d83c@msnews.microsoft.com... > Bill McCarthy <Bill@NOSPAM.com> wrote: >> The problem is more complex than it might first seem. A property >> represents >> a "state" of an object, whereas methods typically indicate something is >> fetched or calculated. So for extension properties you would need a >> state >> store that is associated with an instance. Sure you could do this with a >> static (Shared) dictionary of some sort, but you'd also need to ensure >> you >> use weak references so as you don't inadvertently keep the objects alive. > > No, that would be a bad thing to do - Right it can cause a LOT of issues. [quoted text, click to view] > but a lot of times extension > properties would be useful even if they weren't able to store extra > state. Well then it is a method not a property really. A property should be similar to a field. [quoted text, click to view] > Often they could calculate the value given the existing state. > Sure, but why use a property there when they can use a method ? A method is actually more flexible as you can set a value as well as return a value with the one method. [quoted text, click to view] > Extension properties would also be very useful for writing fluent > interfaces. > Really ? How so ? You can't set a value and return a value with a property.
"Jon Skeet [C# MVP]" <skeet@pobox.com> schrieb:
[quoted text, click to view] >> > If you *really* want to do that in C#, you can use a using directive to >> > introduce an alias. I believe that's clearer in intent than using a >> > variable to make a call to a static method which looks like an instance >> > method. >> >> Right you can alias in VB as well. But in both cases, Vb or C#, writing >> an >> alias for a one of call is overkill really. > > Well yes - but it can be useful when you need to make a call > repeatedly. Java has an interesting approach where you can import > static members, so after something like (my Java is rusty) > > static import java.lang.Math.*; > > you can write > > double x = sqrt(PI*2); > > It's good when used *very sparingly*. You can actually do that in VB too: \\\ Imports System.Math .... Dim x As Double = Sqrt(PI * 2) /// -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://dotnet.mvps.org/dotnet/faqs/>
[quoted text, click to view] "Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message news:0c20a022-2594-4288-ae1f-48c13928c496@v67g2000hse.googlegroups.com... > On Jan 29, 10:22 am, "Bill McCarthy" <B...@NOSPAM.com> wrote: > > <snip> > > >> > Often they could calculate the value given the existing state. >> >> Sure, but why use a property there when they can use a method ? A method >> is >> actually more flexible as you can set a value as well as return a value >> with >> the one method. > > Would you really suggest that all the DateTime properties should be > methods? > They are all read only properties so there is no benifit compared to a method call. [quoted text, click to view] >> > Extension properties would also be very useful for writing fluent >> > interfaces. >> >> Really ? How so ? You can't set a value and return a value with a >> property. > > Um, you don't tend to do that with fluent interfaces. > Since when ? Here, read Martin Fowler on them: http://martinfowler.com/bliki/FluentInterface.html To claim that fluent interfaces are only read only properties is complete nonsense. The whole idea is you can set,fecth, calculate and read in a chained statement. [quoted text, click to view] > Having extension properties would mean being able to write: > > var x = 2.Dollars; > > instead of > > var x = 2.Dollars(); > So that'd be a C# language issue requiring ()'s on methods not properties. [quoted text, click to view] > for instance, or > > var meetingTime = 2.Days.From.Now; > which reads somewhat better than: > var meetingTime = 2.Days().From().Now(); > Again, an issue in C#, not VB ;)
[quoted text, click to view] "Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message news:901fdef3-187a-4498-8748-cce1430ed82d@v67g2000hse.googlegroups.com... >> >> They are all read only properties so there is no benifit compared to a >> method call. > > The benefit is in readability. I wouldn't expect to see many writable > extension properties, but read-only ones would be useful. > Again, there is no readability difference for a method compared to a ReadOnly property, at least not in VB. [quoted text, click to view] >> >> > Um, you don't tend to do that with fluent interfaces. >> >> Since when ? Here, read Martin Fowler on >> them:http://martinfowler.com/bliki/FluentInterface.html > > Okay, "don't tend to" was a bad choice of words. Let me rephrase: > there are plenty of situations using fluent interfaces where you don't > need to pass any parameters, at which point extension properties make > life more readable. > Let me quote to you what Martin Fowler says: <quote> The common convention in the curly brace world is that modifier methods are void, which I like because it follows the principle of CommandQuerySeparation. This convention does get in the way of a fluent interface, so I'm inclined to suspend the convention for this case. </quote> So clearly, Martin is saying that "Properties" as used in C style languages such as C#, does get in the way of a fluent interface. [quoted text, click to view] >> To claim that fluent interfaces are only read only properties is complete >> nonsense. The whole idea is you can set,fecth, calculate and read in a >> chained statement. > > The idea is that you can build what you need to build in the most > readable form. > Again, and extension method provides the same readability. If I read you right, the issue you have is with having to have the ()'s. Well don't you want them there considering with extension methods, and also properties, you can get a null reference exception for the object being extended... something you should never be able to get with properties ;) [quoted text, click to view] >> >> So that'd be a C# language issue requiring ()'s on methods not >> properties. > > Well, I'd argue that's a VB issue of hiding the difference between > methods and properties, but a C# issue of not supporting extension > properties. > VB gives you the choice. C# seems to be forcing you to write things you say are less readable ;) [quoted text, click to view] >> > for instance, or >> >> > var meetingTime = 2.Days.From.Now; >> > which reads somewhat better than: >> > var meetingTime = 2.Days().From().Now(); >> >> Again, an issue in C#, not VB ;) > > Sure. It still means that extension properties are desirable as far as > I'm concerned. > Or make the ()'s optional when calling extension methods.
[quoted text, click to view] "Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message news:9e8570b5-5601-4f04-9585-2c2d71520d2f@k39g2000hsf.googlegroups.com... > On Jan 29, 12:44 pm, "Bill McCarthy" <B...@NOSPAM.com> wrote: >> > The benefit is in readability. I wouldn't expect to see many writable >> > extension properties, but read-only ones would be useful. >> >> Again, there is no readability difference for a method compared to a >> ReadOnly property, at least not in VB. > > Sure - that doesn't stop them being useful in C# though. > Well if this isn't an issue for Vb, yet it is an issue for C#, then perhaps C# should be looking at what VB does already today. [quoted text, click to view] >> >> > Um, you don't tend to do that with fluent interfaces. >> >> >> Since when ? Here, read Martin Fowler on >> >> them:http://martinfowler.com/bliki/FluentInterface.html >> >> > Okay, "don't tend to" was a bad choice of words. Let me rephrase: >> > there are plenty of situations using fluent interfaces where you don't >> > need to pass any parameters, at which point extension properties make >> > life more readable. >> >> Let me quote to you what Martin Fowler says: >> <quote> >> The common convention in the curly brace world is that modifier methods >> are >> void, which I like because it follows the principle of >> CommandQuerySeparation. This convention does get in the way of a fluent >> interface, so I'm inclined to suspend the convention for this case. >> </quote> >> >> So clearly, Martin is saying that "Properties" as used in C style >> languages >> such as C#, does get in the way of a fluent interface. > > Well, I disagree for at least *some* fluent interfaces - because I'd > prefer to make the methods return new values based on the old rather > than changing the existing value. You are talking read only properties; Martin is talking about richer fluency including creation. Just how big is the need for ReadOnly extension properties on immutable types ? I think in virtually all cases you think of, you'll find that you actually start needing to define the types, and hence can place real properties in them. [quoted text, click to view] > This is the way that LINQ works, for > example - you chain together many sequences, rather than changing the > existing one. > LINQ works as extension methods, e.g Count or Sum. [quoted text, click to view] > Other fluent interfaces such as StringBuilder return "this" at the end > of modifying methods like Append, but I certainly wouldn't use an > extension property to do that kind of thing. Ick! In general I prefer > immutable types where they're reasonable, and fluent interfaces work > very well with that pattern. > So you want extension properties only for immutable types and (hence) only ReadOnly properties ? This all for the sake of ommitting the ()'s right ? [quoted text, click to view] >> >> To claim that fluent interfaces are only read only properties is >> >> complete >> >> nonsense. The whole idea is you can set,fecth, calculate and read in >> >> a >> >> chained statement. >> >> > The idea is that you can build what you need to build in the most >> > readable form. >> >> Again, and extension method provides the same readability. If I read you >> right, the issue you have is with having to have the ()'s. Well don't you >> want them there considering with extension methods, and also properties, >> you >> can get a null reference exception for the object being extended... >> something you should never be able to get with properties ;) > > I don't see what bearing NullReferenceExceptions have on the matter at > all. Where's the connection between them and brackets? > An extension method or property (if they were to exist) can be passed a null reference as the object they are extending. Since when does it make sense that a null object has properties and that the property getter (or setter) would get called ?? [quoted text, click to view] > And yes, it's a case of getting rid of the extra parentheses in *some* > cases. > Well that's the only reason so far, and so far you've also limited it to ReadOnly and immutable types. [quoted text, click to view] >> >> So that'd be a C# language issue requiring ()'s on methods not >> >> properties. >> >> > Well, I'd argue that's a VB issue of hiding the difference between >> > methods and properties, but a C# issue of not supporting extension >> > properties. >> >> VB gives you the choice. C# seems to be forcing you to write things you >> say >> are less readable ;) > > In this particular case, yes. It's a very specific case, however, and > in general I'm in favour of C#'s strictness here. > Why ? A property is just a wrapper for a setter and getter. [quoted text, click to view] >> >> Again, an issue in C#, not VB ;) >> >> > Sure. It still means that extension properties are desirable as far as >> > I'm concerned. >> >> Or make the ()'s optional when calling extension methods. > > Ick - I'd very much *not* be in favour of that. Having extension > properties (and potentially even operators) is a much cleaner and more > consistent solution. > Cleaner ? You'd be adding properties that don't exist. If you serialize a type then deserialize it, it doesn't have the same properties. That should be enough to say it isn't clean, it's a poor fudge pretending a type has properties when it does not. If you look at all the issues associated with extension properties, it becomes clear they aren't clean. You have already said you'd basically only use them for ReadOnly properties, and only on immutable types. This just to avoid having ()'s seems to be polluting the language if you ask me. And you need to consider the effect that then has on the CLR and cross language interoperability. Take all these things and weigh them up against having to add ()'s
[quoted text, click to view] "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message news:eHigwaoYIHA.4332@TK2MSFTNGP04.phx.gbl... > "Jon Skeet [C# MVP]" <skeet@pobox.com> schrieb: >>> The problem is more complex than it might first seem. A property >>> represents >>> a "state" of an object, whereas methods typically indicate something is >>> fetched or calculated. So for extension properties you would need a >>> state >>> store that is associated with an instance. Sure you could do this with >>> a >>> static (Shared) dictionary of some sort, but you'd also need to ensure >>> you >>> use weak references so as you don't inadvertently keep the objects >>> alive. >> >> No, that would be a bad thing to do - but a lot of times extension >> properties would be useful even if they weren't able to store extra >> state. Often they could calculate the value given the existing state. > > Amanda Silver of the VB team presented an 'Extends' statement in her talk > about VB's future on TechEd EMEA 2007 which served exactly this purpose: > Extension of existing types with support extra state. This concept goes > far beyond extension methods, which are only syntactic sugar. > Isn't that more to do with mixins ?
[quoted text, click to view] "Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message news:ab25075d-fc85-47dd-a1ef-67f6b0a0f545@u10g2000prn.googlegroups.com... > On Jan 29, 2:05 pm, "Bill McCarthy" <B...@NOSPAM.com> wrote: >> >> Again, there is no readability difference for a method compared to a >> >> ReadOnly property, at least not in VB. >> >> > Sure - that doesn't stop them being useful in C# though. >> >> Well if this isn't an issue for Vb, yet it is an issue for C#, then >> perhaps >> C# should be looking at what VB does already today. > > I believe it should be looking at a mechanism which fits in with > everything that exists today. Extension properties are a natural > extension of where we are today - making brackets optional isn't. > No extension properties are not a natural extension for C#. In fact they go against the C# rule of not allowing parameters to property gets *except* in the case of indexers, in which case you are required ot use [] and the property name Item is hidden. [quoted text, click to view] >> >> So clearly, Martin is saying that "Properties" as used in C style >> >> languages >> >> such as C#, does get in the way of a fluent interface. >> >> > Well, I disagree for at least *some* fluent interfaces - because I'd >> > prefer to make the methods return new values based on the old rather >> > than changing the existing value. >> >> You are talking read only properties; Martin is talking about richer >> fluency >> including creation. > > The properties can create objects with no problems. I don't see what > your objection is here. > You're kidding me right ? The ReadOnly properties can only create a very narrow predefined set of objects based on the public exposed state of the object being extended. You certainly could not be adding line items to a record. [quoted text, click to view] >> Just how big is the need for ReadOnly extension properties on immutable >> types ? I think in virtually all cases you think of, you'll find that >> you >> actually start needing to define the types, and hence can place real >> properties in them. > > Various options with dates and times, numbers etc. > None that require properties though ;) [quoted text, click to view] > Put it this way: I've encountered cases where I'd like to use them, > and others have too (if you search for "extension properties" you'll > find others who wish to use them for fluent interfaces). > Well I haven't seen them. I thought if it was a major issue they'd be well known and well described. If you wish to present soem examples, that'd be good, it may even further the conversation. [quoted text, click to view] >> > This is the way that LINQ works, for >> > example - you chain together many sequences, rather than changing the >> > existing one. >> >> LINQ works as extension methods, e.g Count or Sum. > > Yes, but the point is that those extension methods aren't modifier > methods - they don't change the object they appear to be called on, > they merely return a new one. This isn't the same as the > StringBuilder.Append type behaviour, which is what I believe Martin > was talking about in the quote that you mentioned. > I was commenting about your statement in regards to LINQ not in regards to Martin's statements, so that wasn't the point at all ;) Martin was talking about rich fluent interfaces, something which extension properties in C# would NOT provide. [quoted text, click to view] >> > Other fluent interfaces such as StringBuilder return "this" at the end >> > of modifying methods like Append, but I certainly wouldn't use an >> > extension property to do that kind of thing. Ick! In general I prefer >> > immutable types where they're reasonable, and fluent interfaces work >> > very well with that pattern. >> >> So you want extension properties only for immutable types and (hence) >> only >> ReadOnly properties ? This all for the sake of ommitting the ()'s right >> ? > > Primarily, not necessarily "only". I certainly don't imagine that I > can foresee all possible uses. > Extension properties with setters raise a whole heap of issues. It really is important to step back and look at basic OO principles. They aren't properties of the object and they could only manipulate existing public properties. It's fundamentally wrong to present them as properties. [quoted text, click to view] >> > I don't see what bearing NullReferenceExceptions have on the matter at >> > all. Where's the connection between them and brackets? >> >> An extension method or property (if they were to exist) can be passed a >> null >> reference as the object they are extending. > > Yes, I'm aware of that. > So you think a null reference should have properties ? [quoted text, click to view] >> Since when does it make sense >> that a null object has properties and that the property getter (or >> setter) >> would get called ?? > > I'd guess in a similar set of situations to where it makes sense to > call a method on a null object. Where do you see the difference > between methods and properties here? > OO 101 ;) A method is not claiming to be a property of a non existant object. [quoted text, click to view] >> > And yes, it's a case of getting rid of the extra parentheses in *some* >> > cases. >> >> Well that's the only reason so far, and so far you've also limited it to >> ReadOnly and immutable types. > > In the cases I've wanted to use, yes. > >> > In this particular case, yes. It's a very specific case, however, and >> > in general I'm in favour of C#'s strictness here. >> >> Why ? A property is just a wrapper for a setter and getter. > > Yes, but I believe it's good to know that that's what you're using, > rather than calling a method. > > But hey, that's part of the C# philosophy. > ROFL, now I know you are kidding me. C# hides indexers from you guys because they don't want you to create properties that take parameters. Go-on, have a look at what get's compiled and call it from IL ;) [quoted text, click to view] >> >> Or make the ()'s optional when calling extension methods. >> >> > Ick - I'd very much *not* be in favour of that. Having extension >> > properties (and potentially even operators) is a much cleaner and more >> > consistent solution. >> >> Cleaner ? You'd be adding properties that don't exist. > > In exactly the same way as methods are added which don't exist. > They aren't claiming to be **properties**. [quoted text, click to view] >> If you serialize a >> type then deserialize it, it doesn't have the same properties. > > The extension property values wouldn't be serialized, but that should > be fine because their values should only depend on *other* state. So who defines where that state is ? And how does that state get serialized if it isn't inside the type ? And why don't the getter and setter have the ability to opt in/opt out of xml serialization after all they are *properties* ??? (rhetorical ;)) [quoted text, click to view] > Consider serialization as storing state, and we can't add state with > extension methods or properties. >
[quoted text, click to view] "Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message news:a20e0a6d-06b4-4c5e-a93c-328405213a3b@k2g2000hse.googlegroups.com... > On Jan 29, 3:31 pm, "Bill McCarthy" <B...@NOSPAM.com> wrote: >> > Amanda Silver of the VB team presented an 'Extends' statement in her >> > talk >> > about VB's future on TechEd EMEA 2007 which served exactly this >> > purpose: >> > Extension of existing types with support extra state. This concept >> > goes >> > far beyond extension methods, which are only syntactic sugar. >> >> Isn't that more to do with mixins ? > > Certainly sounds like it - different kettle of fish entirely. (And one > with significant limitations or issues, depending on what's being > proposed. I love the idea of mixins in an appropriate way, and > particularly for interfaces which just delegate to another > implementation, but I think we need to be wary of going too far.) > yeh, I think mixins will be good. Naming issues will be the biggest problems and that's where interfaces would come in handy. They don't necessarily need to delegate out to another implementation though; they can be self contained just as well.
[quoted text, click to view] "Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message news:1d4a74ca-5633-4a0f-97f0-ccba81f423f6@c23g2000hsa.googlegroups.com... >> >> Extension properties with setters raise a whole heap of issues. It >> really >> is important to step back and look at basic OO principles. They aren't >> properties of the object and they could only manipulate existing public >> properties. It's fundamentally wrong to present them as properties. > > Not necessarily. Suppose something had a Size property, but you only > wanted to change the Width. That ends up being: > > foo.Size = new Size (newWidth, foo.Size.Height); > > You could easily encapsulate that in extension properties for Height > and Width. Are there potential issues with properties not being > orthogonal? Sometimes - but sometimes it makes life easier, too. > Okay so let me call you out on this example. show *exactly* how extension properties would solve that and make it easier. |