[fpc-devel] "Default" discussion for SmartPointers etc

[Jonas Maebe]

On 27/07/16 22:47, Sven Barth wrote:
> Am 27.07.2016 21:04 schrieb "Maciej Izak" <hnb.code at gmail.com
> <mailto:hnb.code at gmail.com>>:
>>
>>
>> In that case SmartPtr/SmartObj/Nullable type has no sense for me. The
> basic purpose is excluded. You can do that today by using for example
> proxyobject._.foo();

What is the basic purpose? I did not see any explanation of that in the 
original mail. It only said that it is vital to the smart pointers/ARC 
objects and nullable types implementation.

>> To get rid of @@/@@@ we can use typecast + new type kind. With "proxy"
>> type, Sven proposition has more sense:
>>
>> === code begin ===
>> {$MODE DELPHI}
>>
>> type
>>   TRawSomeSmart<T> = record
>>   private
>>     Instance: T;
>>     ... // normal record
>>   end;
>>
>>   TSomeSmart<T> = proxy to TRawSomeSmart<T>.Instance;
>>
>> var
>>   ptr: pointer;
>>   // PTypeInfo(TypeInfo(ni)).Kind = tkProxy
>>   ni: TSomeSmart<Integer>;
>>   np: TSomeSmart<TProcedure>;
>> begin
>>   ptr := @ni; // pointer to ni.Instance
>>   ptr := @TSomeSmart<Integer>(ni); // pointer to ni
>>
>>   ptr := @@np; // pointer to np.Instance
>>   ptr := @np   // pointer to procedure
>>   ptr := @TSomeSmart<TProcedure>(np); // pointer to np
>> end;
>> === code end ===
>
> Hmm, not that bad either.

I think it is still bad, because it again makes "@X" not return the 
address of X, but of something that X refers to (it's almost like an 
"absolute" declaration). Additionally, declaring a new type 
(TSomeSmart<T>) that refers to an entity inside another type 
(TRawSomeSmart<T>.Instance) looks quite strange (there's nothing like 
that in Pascal yet either, not even to declare forward types).

Before continuing, I think it would be a good idea to look at what the 
desired concept is exactly (transparent proxy objects/references, thin 
wrappers that allow to specify some default behaviour, nullable types, 
... ?) already exists in other programming language (not C++ -- 
everything is just meta-programmed using templates there) and how things 
work there at least from a specification standpoint.

Properly designing a new programming language concept is hard, and the 
worst thing is that once it's shipped, you are stuck with it basically 
forever. I think it needs more than just some example programs and tests 
to design one from scratch.

It's really too bad there is no programming language committee for the 
Pascal language with language design experts that could discuss and 
refine this in-depth. I'm no language design expert myself at all and 
preferably would not even get involved in this kind of discussions but 
at the same time I don't want to get stuck with having to maintain and 
support an ever growing language that becomes less and less 
self-consistent and more and more complex (while there may be simpler or 
clearer ways to achieve the same things).


Jonas