What do you think about that feature request ?
What do you think about that feature request ?
{code}
type
TMyObject = class(TFrame)
private
FError: Integer;
procedure SetError(Value: Integer);
property Error: Integer write SetError; // private setter
public
property Error: Integer read FError; // public getter
end;
{code}
I like to use "Error := callFunction" instead of "SetError(Callfunction)" so the setter is required.
it can be done with a "custom" ancestor, but it's not easy with a TFrame ancestor.
{code}
type
TMyObject = class(TFrame)
private
FError: Integer;
procedure SetError(Value: Integer);
property Error: Integer write SetError; // private setter
public
property Error: Integer read FError; // public getter
end;
{code}
I like to use "Error := callFunction" instead of "SetError(Callfunction)" so the setter is required.
it can be done with a "custom" ancestor, but it's not easy with a TFrame ancestor.
{code}
ReplyDeletetype
TMyObject = class(TFrame)
private
FError: Integer;
procedure SetError(Value: Integer);
property Error: Integer write SetError; overload;
public
property Error: Integer read FError; overload;
end;
{code}
;)
I'd rather have them fix existing language issues first.
ReplyDeleteLike for instance https://gist.github.com/jpluimers/6a3b9eadf96aa6db7958d11a7091b925
Proposed syntax makes little sense in terms of how the language works (cannot define the same identifier twice - E2004). It would rather make sense to be able to add visibility to the read and write keywords in order to be able to write:
ReplyDeletepublic
property Error: Integer read FError private write SetError;
end
Stefan Glienke, yes but then we have a private keyword in a public section. You'd need some rule e.g. the inner visibility can only limit the scope, not expand it to make it deterministic. Still this feature (although targeting a common issue) is not that high on my list. I'd rather have proper closure syntax first.
ReplyDeleteJohan Bontes Yes, visibility modifier should only be more restrictive than the property itself. Its a minor syntax sugar thing though and nothing groundbreaking.
ReplyDeleteVisibility is already a modification of an existing one and you cannot increase visibility beyond what the encompassing entity allows:
ReplyDelete- When adding a `published` section to a class that doesn't emit RTTI yet:
`W1055 PUBLISHED caused RTTI ($M+) to be added to type 'TClass'`
- an empty section has the visibility of the encompassing entity
Since so much got borrowed from it already: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/restricting-accessor-accessibility
Attila Kovacs Congratulation, you just successfully bypassed any logic in the setter.
ReplyDeleteAttila Kovacs
ReplyDeleteprocedure TObject.SetError(Value: Integer);
begin
FError := Value;
if FError <> 0 then
raise Exception.Create('Error ...');
end;
as I said, I don't like to call SetError(...)
Stefan Glienke two properties with the same name, one with a setter and an the other with a getter are not far from an overloaded method. There's no possible confusion between them.
ReplyDeletePaul TOTH Properties are just syntax sugar for reading/writing to a field or calling a getter/setter. So overloading of properties would be some new concept (which possible also would require to add the overload keyword to the property declaration making it even more verbose?) whereas adding a visibility restriction on one of the acessors (either read or write) possibly could be solved way easier. Also splitting the definition of a property into two could cause more confusion when you split them across different classes in some class hierarchy (remember you can change the visibility of a property by redeclaring it). Also remember that by splitting it into 2 property declaration you introduce ways to possible defects by renaming only one of them. That can not happen if you have just one property with a visibility modifier added to read or write to restrict that.
ReplyDeleteStefan Glienke I don't agree with you, there is no possible confusion between a property that define only a setter and one that define only a getter, and as you say they are just syntax sugar. While adding a visibility to a acessor of a property that has already a visibilty scope seems a non-sense to me, it's also to much verbosity
ReplyDeleteproperty some : type index 1 read getsome protected write setsome private default value;
against
private
property some: type index 1 write setsome;
protected
property some: type index 1 read getsome default value;
the only question, is what is the visibilty of a descendant class
public
property some;
and that is propably a good reason to not add this feature.
Given that since their introduction, directives like hint/deprecated are not supported on properties (it's the reason I favour functions over read-only properties), I doubt we will see any languages changes in the properties area soon.
ReplyDeletePaul TOTH What happens if I write this?
ReplyDeleteprivate
property Foo: Integer read FFoo write SetFoo;
public
property Foo: Integer read GetFoo;
end;
Which getter does it use when I access Foo within the class? Direct field access from the private one or via the getter from the public one? What if I access the property from another class in the same unit (remember such a class has private access) Or should the compiler not allow this?`As I said it leads to more problems than it solves and introduces all kinds of possible defects.
Your property declarations are nonsense. Why should the default directive get a visibility modifier? It's only for the streaming mechanism of published properties.
Stefan Glienke I already sayed: "one getter" and "one setter", in your code you define the getter twice.
ReplyDeleteI did not put visibility on the default directive, I've put the keyword after the acessor.
in your code is difficult to know whenever it should be read as
property Error: Integer (read FError private) write SetError;
or
property Error: Integer read FError (private write SetError);
Whatever - I am for less verbosity in the Delphi language and not more - therefor I don't like your proposed syntax. But since they won't put in either the discussion is moot anyway.
ReplyDelete