Hello guys
Hello guys,
New Feature request - Distinct Property Visibilities (Dual-visibility for Properties) - https://quality.embarcadero.com/browse/RSP-13308
Sometimes you want to declare a property that is read-only to the outside world.
Delphi could let us declare a different visibility for the getter and setter of a property. After this new feature, we are able to define properties with different visibility levels for getter and setter, for example allowing public reading and protected writing of properties:
Proposed syntax:
property Count: Int32 read FCount protected write SetCount;
public
property Value: string read FValue protected write FValue;
The visibility for one of the read or write acessors has to match the visibilty section of the class that the property is declared in. This can be achieved by not specifying a visibility (as for read in the example above), or by explicitly repeating the visibility.
Thanks :D
https://quality.embarcadero.com/browse/RSP-13308
New Feature request - Distinct Property Visibilities (Dual-visibility for Properties) - https://quality.embarcadero.com/browse/RSP-13308
Sometimes you want to declare a property that is read-only to the outside world.
Delphi could let us declare a different visibility for the getter and setter of a property. After this new feature, we are able to define properties with different visibility levels for getter and setter, for example allowing public reading and protected writing of properties:
Proposed syntax:
property Count: Int32 read FCount protected write SetCount;
public
property Value: string read FValue protected write FValue;
The visibility for one of the read or write acessors has to match the visibilty section of the class that the property is declared in. This can be achieved by not specifying a visibility (as for read in the example above), or by explicitly repeating the visibility.
Thanks :D
https://quality.embarcadero.com/browse/RSP-13308
I'm not sure of the value for this. I think I'd find it confusing. Something that is read-only is clear. Something that is read-only, except sometimes where it's writeable too, is confusing. I am all for extending the language to make writing code easier, more concise and more clear. (Despite not thinking it's high priority, your 'step' loop keyword of a few hours ago fits all three of these, which is why in principle I support it.) I'm not sure this fits the 'more clear' criteria.
ReplyDeleteWhat I would argue for is the problem when you have properties in interfaces, where the getter and setter have to be public. That makes the implementing class's external view messy to a consumer of the class or interface. I'd like either visibility specifiers in an interface, or to specify a property is read/write but omit the read/write backers, ie only specify the methods in the implementing class declaration. (Something like "property Foo : Integer read write;" in the interface - it's only the class that says "read GetFoo write SetFoo", which lets those methods be private.)
This is extremely easy to achieve by having 2 properties mapped to the same data... but honestly can you give us a realistic use-case scenario?
ReplyDeleteDavid Millington
ReplyDelete>What I would argue for is the problem when you have properties in interfaces, where the getter and setter have to be public.
That is not quite true. The getter and setter on the implementation object can be implemented in the private (strict private?) section and they are still accessible by anything calling that interface property! Confusing, yes.
Having said that, I agree with David Millington, in that I don't think this is required. If I want something to access my variable outside of public, I will create a protected method for doing so. This way, it is quite clear to what is going on - IMO.
I vote for a downvote option in new feature requests.
ReplyDeleteDarian Miller Just comment on the item stating you don't think it is require and the reason(s) behind that decision. That to me, is better than down-voting something, as it passes the reason across as well, so the person that raised the issue can see why people don't like it.
ReplyDeleteMarco Cantù
ReplyDeleteIf you have the following class:
TQueue = class(TInterfacedObject, IEnumerable)
strict private type
TEnumerator = class(TInterfacedObject, IEnumerator)
strict private
FCollection: TQueue;
FIndex: Int32;
FCurrent: T;
FVersion: Int32;
function MoveNext: Boolean;
{$REGION 'Property accessors'}
function GetCurrent: T;
{$ENDREGION}
property Current: T read GetCurrent;
private
constructor Create(const Collection: TQueue);
end;
strict private const
DefaultCapacity = 4;
strict private
FCapacity: Int32;
FItems: TArray;
FComparer: IEqualityComparer;
FHead: Int32;
FTail: Int32;
FCount: Int32;
FVersion: Int32;
procedure EnsureCapacity(MinimumCapacity: Int32);
{$REGION 'Property accessors'}
procedure SetCapacity(Value: Int32);
{$ENDREGION}
public
constructor Create(Capacity: Int32 = DefaultCapacity);
procedure Clear;
function Contains(const Item: T): Boolean;
function Dequeue: T;
procedure Enqueue(const Item: T);
function GetEnumerator: IEnumerator;
function Peek: T;
procedure TrimExcess;
function TryDequeue(out Value: T): Boolean;
function TryPeek(out Value: T): Boolean;
property Capacity: Int32 read FCapacity write SetCapacity;
property Count: Int32 read FCount;
end;
> But you could want to make Capacity property publicly read-only (in other units Capacity only exposes the getter), but in its unit this class can have read and write features hence in its unit you takes care about the values it could get setted. With this new feature you could write the following:
property Capacity: Int32 read FCapacity private write SetCapacity;
When using the autocomplete you won't see the strict private SetCapacity setter method but a fashion property that is readable and writable in its unit, this way the way how the property getter/setter are implemented is solely responsability of the class :D
Darian Miller Downvote hurt people :( Please I suggest you to don't do this :D
ReplyDeleteHorácio Filho Truth hurts sometimes. :D But, I'll concede the point that we should add a note to the idea instead...
ReplyDeleteDarian Miller Downvoting has no truth behind it - and from what I have seen from SO, there is no need to explain why the down vote occurred.
ReplyDeleteIMO, No down voting, just a comment arguing against the change, as there is no way to enforce a valid comment with a down vote.
Marco Cantù This example in C# can help to see this feature request in action:
ReplyDeletepublic class PrettyBag
{
private int _count;
private int[] _items;
public int Count
{
get { return _count; }
protected set
{
if (value < 0)
{
throw new ArgumentOutOfRangeException();
}
if (value = 0)
{
_items = null;
}
_count = value;
}
}
}
public class PrettyBagSon : PrettyBag
{
public void Resize()
{
Count = 0; // non-sense, just an example
}
}
public class PrettyBagTester
{
public void Test()
{
PrettyBag bag = new PrettyBag();
bag.Count = 20; // it doesn't work
PrettyBagSon bagSon = new PrettyBagSon();
bagSon.Count = 20; // it doesn't work too
}
}
You don't touch the setter implementation on derivated classes but is able to use it :D
Properties in Delphi are very powerful, more than most people know, just because they are different from other languages. A Delphi property can be mapped to a virtual protected method, that a derived class can modify. I wrote this in my books 15 years ago... not exactly a new feature, but something most other languages don't have.
ReplyDeleteReaders and writers can have different visibility. An inherited class would use the protected methods (or change them). I really don't see the need for a property with different visibility for read and write.