[PD-dev] moving iemgui from core to extra

[Mathieu Bouchard]

On Fri, 15 Dec 2006, Hans-Christoph Steiner wrote:
>
> If we are going to have full-fledged namespaces, than this is an essential 
> step.  Think C without any #includes or Java without any #imports.

C/C++'s #includes don't have anything to do with namespaces. C doesn't 
have any, and C++ allows you to use namespace-directives in whichever way 
you want regardless of how the #includes work.

Java's "import" directives do implement namespaces, and only namespaces. 
The loading of classes is done by java.lang.ClassLoader, whose closest pd 
equivalent is [objectmaker].

> Only the bare minimum is in the language itself.  Everything else is a 
> library.

Wouldn't it make sense to first categorize built-in classes according to 
which APIs they require, in order to figure out which of them would be 
most logically separable? Basically, every class is separable from pd, but 
that's at the cost of making those new externals depend on a lot of 
undocumented features that are not guaranteed to stay the same over 
releases. For example, <g_canvas.h>, <m_imp.h>, <s_stuff.h>, ...

> The embedded iemgui objects are just an easy place to start, they are already 
> one-class per file.

How do you handle class_addcreator() in that context?

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montréal QC Canada