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

[Alan Hudson]

on vacation till Sept 5th.  So very short reply.

If you code something that provides the service from the execution context
level without adding a per-node variable that's great.  I don't have time
to walk through the ways to implement this and I personally don't need this
functionality.  Any map we have of def name - node should be reversible in
a slow walk of the map.


On Tue, Aug 21, 2012 at 4:05 PM, Don Brutzman <brutzman at nps.edu> wrote:

> 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?)
>
>
if you don't want to listen to our experience on something don't expect us
to bend over backwards to provide proven test cases to show that adding
variables to a class that is replicated thousands to millions of times will
add memory.  My personal goals for Xj3D involve handling large files
efficiently so that's where I spend my time.  If your use cases differs
that's fine but if they conflict then I'm going to put on my project
maintainers hat and say no.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/mailman/private/source_web3d.org/attachments/20120821/fff99ce8/attachment-0001.html>