On 27/07/16 22:47, Sven Barth wrote:
Am 27.07.2016 21:04 schrieb "Maciej Izak" <hnb.c...@gmail.com
<mailto:hnb.c...@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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
