* Immutable and Transient Objects and GC?
@ 2009-03-18 20:07 Dimonax
2009-03-18 21:32 ` Maciej Sobczak
0 siblings, 1 reply; 6+ messages in thread
From: Dimonax @ 2009-03-18 20:07 UTC (permalink / raw)
I'm researching the use of Immutable and Transient data structures in
regards to Concurrent Garbage collection in Ada.
While my focus for the moment is on Garbage Collection, these kinds of
data structures look useful for solving a lot of Concurrent programming
issues.
An Immutable Object, conceptually, is pretty clear. I'm curious as to
what methods you guys might have used to handle them.
Transient Objects, as a formal data type, might be a bit more
challenging. I'd like a Transient Object to behave thusly....
It's created once. It exists until it is accessed one time and one time
only, at which point it's storage is either re-initialized or reclaimed
by the system.
I have some ideas on how this might work. But I'm still dancing around,
trying to figure out how to do it well.
Tips and pointers?
Freejack
aka
Diogenese
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Immutable and Transient Objects and GC?
2009-03-18 20:07 Immutable and Transient Objects and GC? Dimonax
@ 2009-03-18 21:32 ` Maciej Sobczak
2009-03-18 21:50 ` Dimonax
0 siblings, 1 reply; 6+ messages in thread
From: Maciej Sobczak @ 2009-03-18 21:32 UTC (permalink / raw)
On 18 Mar, 21:07, Dimonax <dimo...@nospam.net> wrote:
> An Immutable Object, conceptually, is pretty clear.
Even though there is a bit of hype around immutable objects recently,
related to the hopes that this automagically solves concurrency
problems (which ones, really?), I do not think that it can become a
mainstream approach in languages like Ada.
The problem is that Ada is really a value-oriented language (and not a
reference-oriented one) and there are lots of fundamental language
constructs that promote or even require mutability: 'out' and 'in out'
parameter modes are just examples. Also, there is a strong culture of
avoiding, or at least not overusing, dynamic memory allocation and
this requires mutable state for recycling objects.
In other words, mutability is part of the language spirit.
In addition and just IMHO, immutability cannot be a solution for
anything, because it distorts what should be a natural design of a
given program. What I mean by natural is that (im)mutability of any
given object should come out from the main problem analysis and not
from elsewhere - trying to solve whatever concurrency issues you have
is that "elsewhere" because it has nothing to do with what the given
object represents.
In other words, if the given object *happens* to be immutable as a
result of the problem analysis and this fact can help with
concurrency, then it is a worthy coincidence; but when immutability of
objects is *imposed* in order to solve some unrelated concurrency (or
other) issues, then it is just a design distortion.
--
Maciej Sobczak * www.msobczak.com * www.inspirel.com
Database Access Library for Ada: www.inspirel.com/soci-ada
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Immutable and Transient Objects and GC?
2009-03-18 21:32 ` Maciej Sobczak
@ 2009-03-18 21:50 ` Dimonax
2009-03-19 8:14 ` Maciej Sobczak
0 siblings, 1 reply; 6+ messages in thread
From: Dimonax @ 2009-03-18 21:50 UTC (permalink / raw)
On Wed, 18 Mar 2009 14:32:55 -0700, Maciej Sobczak wrote:
> In other words, if the given object *happens* to be immutable as a
> result of the problem analysis and this fact can help with concurrency,
> then it is a worthy coincidence; but when immutability of objects is
> *imposed* in order to solve some unrelated concurrency (or other)
> issues, then it is just a design distortion.
Good point.
However, what about Transient Objects, which seem to be pretty much the
inverse of Immutable Objects. Ala Forth
They make sense for a lot of data structures, particulary sequential
structures like stacks, queues, etc...
Thier property of being immediately freed upon thier first access means
that I can make a lot of optimizations that arent available to regular
data types.
Freejack
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Immutable and Transient Objects and GC?
2009-03-18 21:50 ` Dimonax
@ 2009-03-19 8:14 ` Maciej Sobczak
2009-03-19 19:23 ` Dimonax
0 siblings, 1 reply; 6+ messages in thread
From: Maciej Sobczak @ 2009-03-19 8:14 UTC (permalink / raw)
On 18 Mar, 22:50, Dimonax <dimo...@nospam.net> wrote:
> Good point.
>
> However, what about Transient Objects, which seem to be pretty much the
> inverse of Immutable Objects. Ala Forth
I have no idea what that is. Could you please elaborate a bit?
> They make sense for a lot of data structures, particulary sequential
> structures like stacks, queues, etc...
Could you please give more details? I have seen and implemented these
structures but I still do not know what is Transient Object.
--
Maciej Sobczak * www.msobczak.com * www.inspirel.com
Database Access Library for Ada: www.inspirel.com/soci-ada
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Immutable and Transient Objects and GC?
2009-03-19 8:14 ` Maciej Sobczak
@ 2009-03-19 19:23 ` Dimonax
2009-03-19 19:57 ` Dmitry A. Kazakov
0 siblings, 1 reply; 6+ messages in thread
From: Dimonax @ 2009-03-19 19:23 UTC (permalink / raw)
On Thu, 19 Mar 2009 01:14:45 -0700, Maciej Sobczak wrote:
> On 18 Mar, 22:50, Dimonax <dimo...@nospam.net> wrote:
> I have no idea what that is. Could you please elaborate a bit?
> Could you please give more details? I have seen and implemented these
> structures but I still do not know what is Transient Object.
To quote http://www.simonbingham.me.uk/2009/02/object-orientated-
programming-oop.html
"Transient
Transient objects are not stored in shared scopes and require separate
instances to provide different behaviour and data. Transient objects
usually represent Domain Objects (e.g. a User or a Product)".
This is what they would be in an OOP paradigm. However the concept is
much more general. If you've ever worked with a Forth machine or a
Concatenative Programming Language(where probably 95% of all the data is
Transient) you'll know exactly what I mean.
Trasient data and objects exist solely for the purpose of being consumed
again.
Since thier always being consumed, storing them in memory usually doesnt
cost much because there are rarely enough of them to be a burden on the
system.
Freejack
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Immutable and Transient Objects and GC?
2009-03-19 19:23 ` Dimonax
@ 2009-03-19 19:57 ` Dmitry A. Kazakov
0 siblings, 0 replies; 6+ messages in thread
From: Dmitry A. Kazakov @ 2009-03-19 19:57 UTC (permalink / raw)
On Thu, 19 Mar 2009 19:23:38 GMT, Dimonax wrote:
> Trasient data and objects exist solely for the purpose of being consumed
> again.
It is not clear why they should have a distinct type. Ada per design is
such that the object type does not depend on the way its scope is managed.
This allows the compiler to create temporal or what you call "transient"
objects as necessary, transparently to the type semantics. For example,
in-out parameters can be copied-in and -out, so that the program would deal
with a "transient" object without knowing it. It is important not to know,
because in other places the compiler could choose by reference parameter
passing for the same type.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-03-19 19:57 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-03-18 20:07 Immutable and Transient Objects and GC? Dimonax
2009-03-18 21:32 ` Maciej Sobczak
2009-03-18 21:50 ` Dimonax
2009-03-19 8:14 ` Maciej Sobczak
2009-03-19 19:23 ` Dimonax
2009-03-19 19:57 ` Dmitry A. Kazakov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox