Do you think that you do not have to define dependencies? Don't be naive do you think that having bloated appliactions in Java is not the problems of DSI? It is. We met some of them in the context of synectique.
The solution is to think modular.
Stef
Java has probably the best solution for this. As you soon as you need a class, it is automatically loaded in memory :-) User do not have to care about all this...
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jun 27, 2014, at 5:04 PM, stepharo <stepharo@free.fr mailto:stepharo@free.fr> wrote:
On 27/6/14 13:38, Alexandre Bergel wrote:
But this solve only partially the problem. How do you reference a class then? I cannot write Smalltalk at: #myclass all the time Another solution would be to put the code that does the exporting in a different package, but this is quite some work.
Sounds that you got the answer. Modularity is not magic but really important.
Stef
Alexandre
On 27 Jun 2014, at 04:32, Nicolas Anquetil <nicolas.anquetil@inria.fr mailto:nicolas.anquetil@inria.fr> wrote:
We could do it by creating a stub class (PDFPage and/or PDFCircleElement in Alexander's example) with a special "new" that would first load the required package ?
nicolas
On 26/06/2014 21:50, Alexandre Bergel wrote:
next time you will be buying stuff in a supermarket you will think about me because you will not buy all the goods in all the rows, Just the one you think you will eat and this is the same with Moose. Why we cannot load XML parser when needed. Because JSON, SVG, XML.... and output depends on the scenario.
I perfectly agree. Ideally, the image should be small, and support loading on demand. However, as fas as I know, there is no such infrastructure in Pharo. How can I load code only when it is needed? I cannot realistically rewrite expressive like
PDFPage new add: (PDFCircleElement new)
into: ((Smalltalk globals includesKey: #PDFPage) ifTrue: [ Smalltalk globals at: #PDFPage ] ifFalse: [ "Gofer invocation to load PDF Exporter" Smalltalk globals at: #PDFPage ]) new add: (Smalltalk at: #PDFCircleElement) new
That would be insane. Loading on demand is indeed important. Java does it pretty well, Pharo should do it too. But infrastructure (even a basic one) is needed for this.
Alexandre
Stef
On 26/6/14 18:05, Alexandre Bergel wrote: > Because if I do something like: > GET2ApplicationExamples new examplePopulationAndArea > > I want to be able to export this very cool graph as a PDF by > clicking on export. It is rare when I use GraphET without > exporting to PDF. > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > On Jun 26, 2014, at 11:55 AM, stepharo <stepharo@free.fr > mailto:stepharo@free.fr> wrote: > >> PS: why do we need artefact (GraphET2 uses it and NeoCSV to me >> this is wrong), XML, loaded into Moose by default > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev