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 ?
No
>> 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
No this would be ridiculous and it shows a problem of design.
When I have a document that I want to export pdf, latex, rtf ... then I
have a visitor and different visitors
for each format!
>
> 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.
This is orthogonal. You have a design problem. I think that this is a
problem to have to load Artefact even if I never ever
generate pdf.
Stef