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

[Don Brutzman]

On 8/21/2012 2:20 PM, Justin Couch wrote:
> On 21/08/2012 3:17 PM, Don Brutzman wrote:
>> I'm afraid that approach is simply insufficient for proper testing.
> 
> The problem is you're trying to test something that should not be tested. You're attacking the wrong problem. In this case, you're seeking a change in the language in order to support poor software engineering, which is always a bad thing to do. DEFs are a load-time only construct. After that they are stripped and thrown away. At run time, everything is handled via direct node references. For example, the ROUTE creation case you are talking about, the API call takes two node references and two field names. It doesn't take DEFs.

I think I defined the problem:  DEF lookup from within Xj3D.  That's all.
If the DEF isn't remembered somewhere somehow, then an X3D scene author
(who is not the same as Xj3D developer) couldn't write a createROUTE call.

> A mapping of DEFs is kept (See X3DExecutionContext), but only within the local context, and not as a property of the node. The only thing it can be used for is to find a node assuming you already know the name, which is consistent with the entire X3D ecosystem. It is not a programming API, it's a scene description and everything is organised around that core concept. You only get access to the things that you already know about and it doesn't break the information encapsulation.

???

If some thing has a unique name label, that is the name label of the thing.
How is it possible to argue with that?  Why would you want to instantly forget the name?

>> We must be able to test and diagnose Xj3D with nontrivial X3D content.
>> You can't just guess which node (among dozens or hundreds) causes an
>> Xj3D error when debugging unit-test content.
> 
> Simple basic software engineering - break the content up in to smaller pieces and only load the bits you want, or load the sub scene. Note also you're talking about unit tests here, which by definition are small pieces of content individually tested, not entire scenes. If the data modelling is correct, unit testing is trivial and also integration testing. As with all software engineering - if the code is difficult to test, then the abstraction is wrong and needs to be refactored until it is easy to test.

That can certainly be a helpful technique, I use it frequently.

However I don't believe that we only need to be able to speak in
clauses.  Sentences, paragraphs, pages, papers, theses, books, etc.
have a role in human thought.  Please don't try to limit us to only
speak in restaurant-menu X3D, larger scenes are needed for testing
of many use cases.

>> Simple, typical approach:  add DEF string to base class for all nodes.
>> Provide get/set accessor methods similar to other fields.
> 
> Except is isn't a field. It's a construction time piece of metadata. Like import/export names, it is not a property of the object, it's a label. You can't make it a property because then you'll break the rest of the X3D model - only one DEF of a given name within an execution context. If you had it as a node property, then it is trivially easy to break the X3D abstract model with this respect. That's why the SAI is designed the way it is - maintain consistency with the X3D abstract model.

OK I guess, but you are giving responses to points I didn't make.

If you call it X3DExecutionContext.getThisIsALabelNottaFieldDEF() that is OK by me.
If you call it X3DExecutionContext.xj3dUtilityMethodLookupNodeDEF(this) that is OK too.
Whatever works to permit debugging of code that is broken 3 out of 10 times.

The context of what I am saying is from within Xj3D, not from SAI.
SAI can be a separate discussion.

Looking forward to getting beyond "you're never allowed to know what was said."

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