27 Jun
2014
27 Jun
'14
11:25 p.m.
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(a)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(a)inria.fr> wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev > 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
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>> On Jun 26, 2014, at 11:55 AM, stepharo <stepharo(a)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(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev