Re: Strong/weak pointers

On 2008-09-01, Michiel Helvensteijn <m.helvensteijn@gmail.com> wrote:


> What we're pondering is: should our language also feature weak
> pointers? A weak pointer cannot be the only pointer to an object
> (since an object requires at least one strong pointer reference to
> exist). And when an object is deallocated because of a lack of strong
> pointer references, all weak pointers referencing it become null. They
> WOULD need their own type notation.


One of the best reasons to add them would be to interface to the outside
world.


The problem is often that you can either wrap each external functionality
(library) manually in some other language to provide your native object
model. But that means that a lot of work has to be done to make an external
library visible from your language, and that must be done in a different
language. And not all users of your language might be fluid in both
framework and the "other" language to do so.


> While this may sound good, weak pointers bring all kinds of conceptual
> nightmares. Like, what should happen if we return a weak pointer from a
> function, or pass it to a function (with in, out or inout)?


I never pondered so much on this issue, but I worked with standard Pascal
and Modula2 that had such restrictions, and nearly all compilers got
extensions over time, and nearly always to interface either with the outside
world, or for own use so that the/a larger part of their own runtime
libraries could be in the native language (as opposed to assembler)


If I had to come up with a solution, and only for interfacing external
functionality, I'd explore the possibility of confining lowlevel features in
general to certain parts (modules) of the program.


The problem is less that a lot of languages have escapes from their own
rigidities for interfacing purposes, but more that these are then allowed
everywhere, far beyond their initial uses.


IOW maybe you can confine lowlevel uses to certain modules, and never let the
weak pointers (and any objects they could still point to) out of those
"interfacing" modules by estabilishing special declarations etc.


That way you at least provide an escape to your own rigid language model,
and allow interfacing to the outside world. Also other stuff associated with
C level imperative languages, but required for interfacing to them, like
aligment, packing, calling convention changes, objects not referenced in
your system, but that need to kept alive because of external callbacks etc
could be kept there in isolation.


This would allow a programmer to siphon data in the own language from
external libs from the more statically and manually allocated world into
your GCed world, and the a bit the same with behaviour (like external
callbacks/events)


And also it might also allow you to do a larger part of the standard
libraries in your own language.


> We're not sure, so we may leave weak pointers out of the language IF we
> cannot find a convincing case for keeping them, and an elegant solution for
> passing them around. Note that such a solution may be to eliminate our (in,
> out, inout) parameter modifiers in favor of something like 'pass by value'
> and 'pass by reference'.
>
> We would appreciate opinions on this. In particular, can you think of any
> good use-cases for weak pointers? Would it be a big loss if we left them
> out? Note that it is impossible to 'simulate' them with strong pointers, so
> it is an important issue.


Start thinking beyond the initial language design, and its daily use. E.g.
if your language is purely mathematical you might not need much external
interfacing.

Return to the comp.compilers page.
Search the comp.compilers archives again.