I wish, Delphi could get this aswell:
I wish, Delphi could get this aswell:
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2427047-add-nameof-operator-in-c
And C# 6 brings much more nice syntax sugar to enhance the code (most of it makes the code less verbose and easier to read and write)
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2427047-add-nameof-operator-in-c
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2427047-add-nameof-operator-in-c
And C# 6 brings much more nice syntax sugar to enhance the code (most of it makes the code less verbose and easier to read and write)
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2427047-add-nameof-operator-in-c
A function seems enough to me. No need to add such syntax sugar IMHO. We are very far from the pascal way of doing it. Perhaps a record helper on typeinfo() may make better sense.
ReplyDeleteI'd prefer compile time naming, not runtime through RTTI.
ReplyDeleteA. Bouchez What exactly is not pascalish about a NameOf(x: Identifier) compiler magic function? I cannot think of a way that would be any more pascalish than that.
ReplyDeleteA. Bouchez - F.x. LiveBinding is based on connecting properties through RTTI lookup by string literals. It would solidify the code signficantly if this could be done through NameOf(TMyClass.MyProperty) and/or NameOf(MyClassInstance.MyProperty) as string literals are not changed by Refactoring renaming.
ReplyDeleteA. Bouchez Eh? Are you really suggesting trading a compiler generated const string for runtime code to look up a member name? TypeInfo returns as it says info about a type. What we need here is the name of a member. There is no easy one for all typeinfo structure for members.
ReplyDeleteAs for the pascalish or C# or whatever discussion. I just ignore that. In fact I don't f*ing care if something does not look pascalish as long as it works properly. This pascalish or not argument is like racism....
Stefan Glienke No, of course, I was still writing about accessing a read-only constant string member at compile time, directly from TypeInfo().
ReplyDeleteRuntime is not evil, BTW. And much easier to debug, from my own experiment - this is were AOP magic fails, e.g. even on C#. Just check some restrictions of the new "native" mode of DotNet, when used with most advanced AOP frameworks - complex heuristic has to take place, or some injection features are not even possible.
You are right: I suppose we would reach Godwin's law soon in this discussion.
:)
A. Bouchez I still fail to get your point.
ReplyDeleteLet's take some examples that are similar to those from the various articles about C# 6.0 and nameof.
Assert(myVariable = 0, NameOf(myVariable) + ' must be zero.)
or
CreateBinding(Self, NameOf(CompanyName), ...)
or
procedure TCustomer.SetCompanyName(const value: string);
begin
if fCompanyName <> value then
begin
fCompanyName := value;
NotifyOfPropertyChange(NameOf(CompanyName));
end;
end;
How can these use TypeInfo to get the names of the identifiers?
About AOP: The way AOP is done by PostSharp and others are just workarounds imo. AOP done right is integrated into the compiler like RemObjects Cirrus does it.
Stefan Glienke My mistake, I was assuming this was a shortcut to TTypeInfo.Name property. And this NameOf() is a shortcut to the variable name. It would allow strong typing of variable names.
ReplyDeleteFor properties, I sometimes used TCustomer(nil).CompanyName, then figured out the property from RTTI, from its offset. This work since earlier versions of Delphi.
AOP via Cirrus is done only at compile time, whereas the main benefit of AOP is about applying it at runtime, depending on the execution circumstances, IMHO. Just like PostSharp does, and Native DotNet has issues with.
A. Bouchez Now you finally got it :P
ReplyDeleteFWIW the main benefit of AOP is separating core and system level concerns no matter if they are getting applied at compile or runtime. If you can apply these aspects dynamically at runtime that is another benefit, that is right. But PostSharp does not do that either afaik (it's just a huge post compile hack that is possible because of being able to modify IL so "easily"). Castle DynamicProxy can apply aspects dynamically and is used by many other projects.
Even better than NAMEOF, in my opinion would be a _LINE_, _FILE_ and _FUNCTION_, and function macros. Yes, for logging/instrumentation.
ReplyDeleteWarren Postma Since Assert can do it i would see no reason to not provide such macros (though not with that ugly underscores ;)
ReplyDeleteThose ugly underscores prevent breaking your code everywhere where you had already placed a variable named Line, or File, or Function. This goes double in Pascal where it's case insensitive.
ReplyDeleteIf Assert could be inlined (to be more precisely the compiled in arguments) that would solve at least getting the line and file.
ReplyDeleteEurekaLog has a CurrentInstruction type of function that can get the current point of execution in stack form, but - it is costly.
ReplyDeleteAnd it most certainly only works when debuginfo or mapfile is available, whoops.
ReplyDeleteJclDebug and madExcept have these methods as well
https://quality.embarcadero.com/browse/RSP-13290 - NameOf feature request.
ReplyDeleteHorácio Filho - Feel free to repost under Delphi Feature Request and ask people to upvote.
ReplyDeleteLars Fosdal I will do it, thanks man :D
ReplyDelete