dare I mention Craig Latta's Spoon project which explicitly is meant to
solve this issue?
L
On 2/3/13 1:42 PM, Igor Stasenko wrote:
On 3 February 2013 20:53, Miguel Moquillon <[email protected]> wrote:
Le 03/02/2013 19:27, Denis Kudriashov a écrit :
2013/2/3 Miguel Moquillon <[email protected]
<mailto:[email protected]>>
And the Java people are preparing to throw away the classloaders
mechanism with Jigsaw that will be in Java 9. (The classloading is a
brittle and error-prone mechanism.) The aim of jigswa is to design
and implement a new module system for the Java SE platform and to
apply that system to the platform itself and to the JDK (more
information in the project homepage
http://openjdk.java.net/projects/jigsaw/
<http://openjdk.java.net/projects/jigsaw/>).
Miguel
I know about this. But let's talk about pharo. Now pharo can't do
this. You can't have two versions of same package at same time in
image. So how we can implement it? And do this is really important?
IMHO, it is not important and should be avoided because it is error-prone
(what is the actual version used by the objects?). This can even be a
nightmare with a lot of dependencies when an error occurs.
Don't forget: keep things simple (it is always more easily to build too more
complex systems).
Having a program depending on a package in two different versions at the
same time in an image is in my opinion a design error. And if your program
depends on some tiers-party packages that depend on a different version of a
same package, then you should decide for the more recent one (or according
to other heuristic) and fix, if needed, the dependency in the others
packages. This is more easy to do with Pharo than with Java.
Even in Java, we take care to avoid these situations by using a dependency
exclusion with Maven.
+1. From a first sight, it looks like we are missing features to
support such cases (like having two
different versions of same class because of dependencies), but if we
look at results of having this,
it is apparent that it will serve as a source of confusion, and while
in perfect cases this will work fine,
i would hate knowing that my project, in order to function properly,
requires two different versions
of same class (or package) and avoid this at all costs.
I think this problem stems from having a proprietary code, which you
cannot control or change,
but since in pharo we don't have such 'frozen & closed' code, all the
problems with dependencies
can be solved in more traditional manner: by fixing them :)
Miguel
--
Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the
(almost) complete and compleate beginner).
https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all
"Debugging is twice as hard as writing the code in the first place. Therefore, if
you write the code as cleverly as possible, you are, by definition, not smart enough to
debug it." - Brian Kernighan
