[Source] Extrusion diagnostics improved; how to get the DEF name of a node?

[Don Brutzman]

On 8/21/2012 9:28 PM, Alan Hudson wrote:
> On 8/21/2012 11:47 AM, Richard Puk wrote:
>  Hi, Alan --
>> 
>> Perhaps you can have your cake and eat it too. Why not provide a run-time
>> switch that either enables the saving of DEF names or disables it?

Very constructive suggestion, thanks Dick.

> you can't unallocate class variables at runtime so if there is a slot for it in the class then it consumes memory.

So maybe a similar approach might work?
- Empty strings consume very little memory.
- Empty hash tables consume very little memory.
- Some other on-demand approach perhaps?

I've asked for a testing-support mechanism and
- suggested several approaches,
- worked diligently to not break anything,
- asked a series of questions,
- emphasized testing for debugging broken parts of Xj3D
- emphasized testing for making architectural judgements
- remained polite and cooperative, looking for common ground
	in order to achieve greatest shared good

You guys have hinted that some mechanism exists in X3DExecutionContext
but declined to explain how that might work.  I looked there to determine
what you might be saying, is it something like lines 42-48:

>     public void readableFieldChanged(X3DFieldEvent evt) {
>         System.out.println("Clicked!");
>         X3DExecutionContext ec=myBrowser.getExecutionContext();
>         if(myRoute==null) {
>             System.out.println("Route added");
>             myRoute=ec.addRoute(ec.getNamedNode("OI"),"value_changed",
>                                 ec.getNamedNode("greenBox"),"set_rotation");

That would only seem to work for retrieving an X3DNode if DEF name
is known.  I'm asking how, or how best, to do the opposite:  given
an X3DNode (presumably a 'this' reference), how to retrieve the
corresponding DEF name?  Maybe I'm missing something but I still don't
see that capability in there.

When one goes to X3DExecutionContext and look up getNamedNode() to try to
decipher your pattern, one finds... an interface definition with no method
bodies.  If one then goes to look up the implementations of this interface,
there are four implementers/overriders:  BaseExecutionContext, SAIScene,
WorldScene, and X3DScene.  So you already have multiple ways to override
the base classes depending on execution context... which would be yet
another general approach to decide where to put a utility method, with
at least four variants that exist.  Once again, hat in hand, am asking
what guidance might experienced Xj3D programmers provide about the best
way to accomplish this fundamental but nontrivial task?

Instead you are both making forceful arguments that appear to say:
- you don't and won't do it that in any way, because you haven't
- no tests are needed to justify past assertions, they are simply true
  unless proven otherwise
- if i (or presumably anyone else) asks again after "no," then they
  don't understand open source (personal attack?) or should just fork off
  (discouraging common understanding, best practices, community building?)

I doubt that you want to communicate such sentiments, especially after
multiple recent meetings where we made cooperative and constructive plans
together.  Regrettably it comes across that way... am hoping you recall
the many efforts that our team has made to support Xj3D code development
without blocking your work.  Many people appreciate your efforts, and are
actively spending their valuable time to demonstrate further improvements.
We remain part of that list.

I'm simply interested in progress, and expect that you both are too.

Let's continue improving, together please.  Am still hoping to somehow
look up a DEF name while developing and debugging Xj3D source code.

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman