Forbidding may be a bit strong. But in general think it better to find
some pattern to avoid it.
Bob.
On 17/11/06, Linus Tolke <[EMAIL PROTECTED]> wrote:
Well said!
I had started a mail to say part of this but I was not this clear in the
problem analysis.
Isn't there a design rule forbidding reflection already? Shall we add
one?
/Linus
> -----Original Message-----
> From: Tom Morris [mailto:[EMAIL PROTECTED]
> Sent: den 14 november 2006 23:18
> To: [email protected]
> Subject: RE: [argouml-dev] Problem with the persistence/load of
diagrams.
>
> I think that the the classloader problem, while perhaps tricky, is
> definitely solvable.
>
> I don't think Bob's workaround is necessary, but as a general comment
on
> the
> topic he raised:
>
> > It seems that you can call the constructors of your own Figs
> > but creating by reflection has problems.
> >
> > So what I can do is provide an API in GEF where an
> > application can register a factory object to create diagrams.
>
> I think moving away from using reflection is a good idea. Having the
> diagram parser depend on an implied interface based on our internal
class
> structure has proven to be quite fragile and I think a more formal
> interface
> is needed. Using reflection removes that formality. For something
like a
> file format, having a stable, formally reviewed, slowly changing (or
> non-changing) interface is a good thing.
>
> Having said that if we're going to support pluggable diagram types, I
> think
> we should think through how this is done. What happens if I send my
> project
> to someone that doesn't have the module installed? Can they see the
shape
> of the diagram, but not act on it? Does the whole project fail to
load?
> How are they informed what module they need and where they get it?
> Personally, I think they should be able to see and print the diagram
even
> if
> they don't have the module installed.
>
> Also, since GEF is nominally separate from ArgoUML, we shouldn't be
> directly
> exposing any of its internal APIs since this makes it impossible to
> change/replace in the future. (cf LeakyAbstraction)
>
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
