None in the std libs of Berlin/Tokyo/Rio. Possibly because there are so very many varying needs for formatting of date and time within the same application.
Lars Fosdal Strange, I would have expected at least SomeDate.ToString() to be implemented - defaulting to the system's current locale formatting. That would be the most obvious implementation. Oh well, the implementation suggestion mentioned by Leif Uneus seems like a good option.
Yes. I've been revisiting and bringing my C# knowledge up to scratch of late. Heresy! ;) But seriously, this "one active class helper" limitation in Delphi makes this feature far less flexible it seems to me than it should be. C#'s extension methods by comparison are very flexible. You can declare as many as you like in different or the same namespace and/or in the same or different files if you want. And any name collisions/ambiguities are flagged up by the compiler and require explicit disambiguation via calling the required static method (in Delphi "class method") explicitly, which is fair enough. Anyway!
And as the comments in Marco's articles show... One again FPC developers used their brains, quickly foresaw the issue and realised there is technically nothing stopping them implementing type helper inheritance, so added that. Another thing going for FPC.
Graeme Geldenhuys Actually that's interesting, thanks for mentioning. It's one thing that FPC then has on both C# (and Delphi.) In C#, while as mentioned you can have multiple class helpers (extension classes), you cannot however have one inherit from another to allow one to extend it, because extensions classes are static (comprised of static only methods) and C# does not support virtual static (class) methods, only virtual instance methods (due to I think technical implementation details due to either .Net or the C# compiler itself, I don't know which, I haven't looked into the why of it.) It did bug me a little when I noticed that but whatever.
Graeme Geldenhuys You really think that helper inheritance is a beautiful solution? Well yes its better than nothing but still it requires a strict hierarchy. What if 3rd party A and B both want to extend on some existing helper? You still end with only using either the one from A or B. C# extension methods are treated like overloads - if you have any conflicting ones because you have two different ones in scope then the compiler will tell you. And that only when the calling code is not in any namespace of the extensions reducing the risk of other extension methods clashing with the ones you have.
Oh and then the neat fact that extension methods can have a generic this parameter meaning they extend any type (freaking nice for DDL or in unit testing). Try that with a helper.
Stefan Glienke : > ou really think that helper inheritance is a beautiful solution?
Did I said that? Type helpers are a love/hate relationship, just like the WITH statement.
If you have a moment, take a look at the Inheritance and Scope documentation listed in the URL below. Note that the scope is rather important. FPC allows multiple type helpers for the same type in the same program, but only one can be in the current scope - the usual scope rules of the Pascal language applies.
"only one can be in the current scope" I know and it's crap - it's way too easy to hide an existing helper and introduce defects. And while I use helpers sometimes to replace behavior of existing methods on the type itself strictly speaking this is a design defect as well because again you can introduce bugs by this just by putting a helper with such a method into scope. Extension methods in C# cannot and must not do that.
github.com - colinj/TDateTimeHelper
ReplyDeleteNone in the std libs of Berlin/Tokyo/Rio. Possibly because there are so very many varying needs for formatting of date and time within the same application.
ReplyDeleteLars Fosdal Strange, I would have expected at least SomeDate.ToString() to be implemented - defaulting to the system's current locale formatting. That would be the most obvious implementation. Oh well, the implementation suggestion mentioned by Leif Uneus seems like a good option.
ReplyDeleteWhen record helpers for intrinsic types was introduced in XE3, Marco Cantù exemplified the above TDateTime helper as one of the community shared helpers.
ReplyDeleteblog.marcocantu.com - Delphi XE3: Record Helpers for Intrinsic Types
Yes. I've been revisiting and bringing my C# knowledge up to scratch of late. Heresy! ;) But seriously, this "one active class helper" limitation in Delphi makes this feature far less flexible it seems to me than it should be. C#'s extension methods by comparison are very flexible. You can declare as many as you like in different or the same namespace and/or in the same or different files if you want. And any name collisions/ambiguities are flagged up by the compiler and require explicit disambiguation via calling the required static method (in Delphi "class method") explicitly, which is fair enough. Anyway!
ReplyDeleteWalter Prins Nothing heretic about that - only to those xenophobic pascal fundamentalists. :)
ReplyDeleteAnd yes, I agree on the only one limitation - it shows the entire feature was originally only designed to be a crutch.
And as the comments in Marco's articles show... One again FPC developers used their brains, quickly foresaw the issue and realised there is technically nothing stopping them implementing type helper inheritance, so added that. Another thing going for FPC.
ReplyDeleteGraeme Geldenhuys Actually that's interesting, thanks for mentioning. It's one thing that FPC then has on both C# (and Delphi.) In C#, while as mentioned you can have multiple class helpers (extension classes), you cannot however have one inherit from another to allow one to extend it, because extensions classes are static (comprised of static only methods) and C# does not support virtual static (class) methods, only virtual instance methods (due to I think technical implementation details due to either .Net or the C# compiler itself, I don't know which, I haven't looked into the why of it.) It did bug me a little when I noticed that but whatever.
ReplyDeleteGraeme Geldenhuys You really think that helper inheritance is a beautiful solution? Well yes its better than nothing but still it requires a strict hierarchy.
ReplyDeleteWhat if 3rd party A and B both want to extend on some existing helper? You still end with only using either the one from A or B. C# extension methods are treated like overloads - if you have any conflicting ones because you have two different ones in scope then the compiler will tell you. And that only when the calling code is not in any namespace of the extensions reducing the risk of other extension methods clashing with the ones you have.
Oh and then the neat fact that extension methods can have a generic this parameter meaning they extend any type (freaking nice for DDL or in unit testing). Try that with a helper.
I really miss stuff like...
ReplyDelete- generics for helpers
TMyHelper = record helper for TMyType;
- inheritance or extensions for helpers
TMyHelper = record helper extending TSomeOtherHelper;
- the ability to have a helper adher to an interface specification
TMyHelper = record helper for TMyType implements IMyStandardHelperInterface;
- overriding helper scope
TBaseType.Default.Method
TBaseType.TMyHelperType.Method
Stefan Glienke : > ou really think that helper inheritance is a beautiful solution?
ReplyDeleteDid I said that? Type helpers are a love/hate relationship, just like the WITH statement.
If you have a moment, take a look at the Inheritance and Scope documentation listed in the URL below. Note that the scope is rather important. FPC allows multiple type helpers for the same type in the same program, but only one can be in the current scope - the usual scope rules of the Pascal language applies.
wiki.freepascal.org - Helper types - Free Pascal wiki
"only one can be in the current scope"
ReplyDeleteI know and it's crap - it's way too easy to hide an existing helper and introduce defects. And while I use helpers sometimes to replace behavior of existing methods on the type itself strictly speaking this is a design defect as well because again you can introduce bugs by this just by putting a helper with such a method into scope. Extension methods in C# cannot and must not do that.