Still HTML, but my Outlook can deal with it. I will leave the full
post here so that others can read it.
The RunTime idea as resource manager makes a lot of sense. However,
I am wondering how much flexibility does it cut, being a singleton.
But I do not know enough yet to criticize any of these options and
the RunTime sure makes typical use very simple.
=:o)
I will make my home work and come back at all this later.
=:o)
Have fun,
Paulo
-----Original Message-----
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 05, 2001 16:39
I can't get this toy mail client to not attach HTML as well. Sorry. It's
telling me it's text... really...
> -----Original Message-----
> From: Paulo Gaspar [mailto:[EMAIL PROTECTED]]
>
> > We must be using the term 'parser' differently. Currently,
> the parser has
> > *no* understanding of discovery rules. The discovery rules are
> implemented
> > in the nodes within the syntax tree.
>
> Of course. That is why I said, about the Parser class:
> "The Parser is just a convenient holder for the reference to the
> IntrospectionBuilder which avoids extra references."
So is Runtime, since it's a singleton instance, deals with properties, and
is currently a central resource manager.
> My "convenient" is directly connected with "avoids extra
> references" and so
> on.
> It has to do with performance/flexibility concerns.
Either way, each node that needs the discoverer would have to hold a
reference, or make a method call per use. (yuk).
> The Parser class is also where the ASTIdentifierNode, ASTMethod,
> ASTIdentifier
> and ASTReference nodes are created. That also makes it easier
> to set what
> strategy such nodes should use - without knowing whatever
> that strategy
> really
> does, of course.
Yes, 'created' as in 'new <class>'. Another approach, since this would most
likely wind up as yet another property, and therefore Runtime might know
about this anyway, would to let Runtime own a singleton instance of the
'discoverer', and then the CTOR of the nodes that care just get a reference
to it from Runtime when created. This supports the idea of Runtime as the
central core resource manager. If discovery is unrelated to the actions of
the parser (which it is now), my vote would be to let the resource-managing
Runtime class handle it. But I guess we can see how it works out.
> Thanks a lot. I think that ASTIdentifier would be enough for
> my needs but I
> am still volunteer to centralize introspection calls and make
> the thing
> plugable.
Cool. I think that we already have a simple solution by combining into one
class the logic in Indentifier (combine GetExec and PropertyExec), and that
could be pluggable.
If we limited the expandablility to that, you would be satisified, and we
would limit the responsiblities / risks of replacement discovery mechanisms.
> What about if I give it a try, test it and get back to you
> with the changes
> I made, so you can evaluate it?
As you say, 'Have fun'.
:)
geir
p.s. Just if I haven't mentioned it about a million times,sorry about the
crummy MSFT mail client... not at home at the moment :)
