@Araq:
> The hooks of tuples are lifted from their components' hooks
Having direct custom hooks for tuples was just a suggestion. Reading the
documentation, tuples and objects are grouped together, and the alternate
declaration syntax for tuples makes them look like objects,, there is the the
same alternate way of constructing named tuples, and the same alternate way of
using a default named tuple constructor and named fields; I just thought it
made sense that there might be the same capability of adding custom hooks
directly to tuples as there is to objects.
However, if one needs to do this, one can just use an object instead of a tuple
and apply the custom hooks to the object, since the syntax would be the same.
For tuples inside a ref structure, my tests seem to indicate that tuple
contents **aren 't** destroyed and for any tuple that contains other than a
primitive, we get an error when we trigger automatic destructor generation for
a tuple containing a destroyable object as in the following:
type
Foo = object
cntnts: int
proc `=destroy`(x: var Foo) =
echo "destroying Foo"
x.reset
var t = (33, Foo(cntnts: 42)); t.`=destroy`; t.echo
Run
where the error turns out to be "Error: internal error: destructor turned out
to be not trivial". Perhaps that's just a bug in the current version 0.20.0?
> It works for C++...
I don't think that is a good argument, as I consider Nim good because it isn't
C++ and better when one no longer cares for the whole OOP paradigm...
> Likewise, having owned(proc ())...
That would mean you've extended the definition of "owned" to beyond just owned
ref as was in the spec 2 and I was trying to make everything fit within that
spec. A simple "nimcall" proc is just a pointer to a proc implementation but a
"closure" is actually a tuple of two pointers, one to the proc and one to the
environment on the heap. However, your implementation works if the concept of
owned is extended to tuples/objects as it would protect the interior pointers
in the same way as an owned ref would do without the indirection as you say.
If owned were applied to the motivating example, then that would also work with
the same advantages I mentioned of allowing pointers of the same fields inside
the owned have the same target and shallow copying by default as per the
specification for owned/non-owned items.
Given that you've extended the spec 2 so that owned can be applied to anything
especially including object and tuple containers (as well as perhaps pointer
and ptr T to go with ref?), then the extra indirection isn't necessary when the
owned object is a pointer or in the case of closures a pair of pointers.
Also, you then might need the definition of the "owned" keyword unless every
object was owned by default, in which case the alternate of only having an
"unowned" or "dangling" keyword could be available for the rare cases where one
needs to specify this manually in a type signature.
What I wrote then stands other than point 3) as it considered the spec 2
exactly as not having anything other than owned ref; I think that the rest
after skipping the extra indirection is still valid?
Even the motivating example still needs to be changed as it needs to be
specified that the seq object type is owned and consideration made for that in
the "hooks"; I think that most owned/not owned objects would be able to use a
default set of "hooks" something like the ones as proposed for the
owned/unowned ref's. Next, I'll provide an implementation that would allow this
default "hooks" following on from other data than just ref being able to be
owned...
