[fpc-devel] Management operators : Copy and Clone confusion...

Maciej Izak hnb.code at gmail.com
Thu Jan 19 11:34:06 CET 2017


2017-01-19 10:44 GMT+01:00 Michael Van Canneyt <michael at freepascal.org>:
>
> At the risk of writing nonsense:
>

Seems ok to me :)


>
> I would think that a method name should give a clue as to what it actually
> does.
> In that sense AddRef/Clone seems better to me ?
> (unless Copy does something else besides increasing the ref count ?)
>
> AddRef is clear to anyone, I think.
>
> If I see "Clone", I immediatly think of an object whose properties are a
> copy of
> the original, but which otherwise has nothing to do with the original.


current "Clone" works like expected:

(1)
https://github.com/maciej-izak/PascalSmartPointers/blob/1ecf773128b523a328a11f30a9b766858ac57c99/sources/SmartObj.pas#L63-L77
(2)
https://github.com/maciej-izak/PascalSmartPointers/blob/1ecf773128b523a328a11f30a9b766858ac57c99/sources/SmartPtr.pas#L62-L76

"Copy" in (1) and (2) looks somehow strange for me. But for example for
Nullable type, convention proposed by Florian is not bad:

(3)
https://github.com/maciej-izak/PascalSmartPointers/blob/1ecf773128b523a328a11f30a9b766858ac57c99/sources/Nullable.pas#L115-L143

"Clone" seems like right move for all examples. But together with "Copy"
IMO is crappy. AddRef in (3) is not correct at all but for (1) and (2) is
perfect.

Maybe I thinking too much by RTL and Copy/Clone is not that bad? Anyway is
hard for me to ignore RTL...

Copy operator with single parameter seems for me really strange. When I
starting any of new code for management operators my first declaration
looks like:

class operator Copy(constref Src: T; var Dest: T); // >.< meh...

TLTR:
Clone might stay as-is but what with "class operator Copy(var Rec:
TNullable<T>);"? AddRef for example (3) might be bad idea. Current pair
Copy/Clone operators is used in different context for different ideas. At
the end RTL naming convention (AddRef/Copy) might be not bad...

-- 
Best regards,
Maciej Izak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20170119/4da14f7b/attachment.html>


More information about the fpc-devel mailing list