[Grace-core] Dialect Design Proposal

Marco Servetto marco.servetto at gmail.com
Mon Nov 26 21:07:03 PST 2012


> so lets say one module provides access to GTK.
> There may be global state associated with GTK (or a database or whatever)
> that will be anchored in the module object...
and so? should not such global state be duplicated if two different
instances use the database?

>> If we support statefull modules, sharing the instance of (private)
>> submodules is going to have unpredictable behavior and/or breaking
>> encapsulation.
> well that's up to whoever programmed the module…
Not really, how can the module know if it is shared or not?
For the best of my little knowledge, in C# there is the possibility of
choosing if a module should have "multiple instances" or an "aliased
reference"
and (again, modulo my ignorance) usually with aliased references you
need to "give" the reference of the module to the assembly explicitly,
similarly to what happen in Java when you have to provide the "library
jars" in the classpath, while the first one (module duplication) can
be obtained with "fat jars" that basically copy jars inside other
jars.
Do we want to bind grace to this model of modules? where if a module
uses submodules the final client have to know ALL the indirectly used
submodules, thus breaking the encapsulation logic of "private
sub-modules"?

What is newspeak doing on this point?
Is not using parametric modules (i.e. methods) to take as parameters
"possible shared" submodules and just coping as new nested classes the
"private modules"?
(de-facto reversing the "java default" )


More information about the Grace-core mailing list