Subject:
|
Re: A comprehensive LDraw object model
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Mon, 11 Feb 2002 09:30:07 GMT
|
Viewed:
|
531 times
|
| |
|
|
"Sproaticus" <jsproat@io.com> schrieb im Newsbeitrag news:GrBy72.EJI@lugnet.com...
> > Else they are container classes, there have to be wrapper
> > depending on the intention of the program. In this case we rebuild
> > the dat-file structure.
>
> That's exactly what I propose, is to rebuild the dat-file structure in an
> object-oriented way.
Conclusion:
The LineType-classes are wrapper classes for the lines in the dat files.
Simple in- and output methods are included, also simple transforming methods,
eg. translation / rotation of the element.
All other (complexer, special) modifications and views are separated from them.
> OTOH, the datfile format has been extended to simulate a single-depth
> container of datfiles. Most LDraw tools correctly handle DATs and MPDs when
> you use them as input. But with any of these tools, just try to put an MPD
> partname in a line type 1 and things start to break.
I prefer the DAT/LDR as a special case of MPD: it contains only one part.
This should be closer to the object oriented way.
Ergo if you have a list of Parts in a file (a single part is a list too),
managing them as a unit or part by part, outside it's looking as one object.
> This tells me that DATs and MPDs are different animals, and unrelated to
> type 1 lines.
OK, I was wrong to equate file and linetype.
> > > *** LDRAW DAT RENDERER CLASSES ***
> > > abstract class LDrawRenderer - ancestor class for renderers
> > > + class LDrawRendererOrthographic - renders LDraw.exe style
> > This should not be declared because it prevents using different libraries
> > (native code) on different systems. I think that this is highly differing
> > from the programmer and it's tools.
> How do you mean? If we were to implement an example renderer in 100% Java
> (or Perl or Python, etc.), would that not be runnable on different systems
> -- including systems where there's a Java (or Perl or Python, etc.) presense
> but no native LDraw tools? The only libraries needed would be the JRE (or
> Perl or Python, etc.) and this class library.
> Please explain, as I'm not quite sold on this part of my class structure
> anyway...
The naming is not good. Calling them viewing classes is much better.
So you can include text-based views / modifications, a renderer is only a
special case of a view.
I don't know, how precise you can define your view class to let it be general
for the utilization someone else wants.
Maybe an interface where loading and changing functions are required, and
eventually passing inputs to our ldraw-wrapper/container classes, all other
is by the programmer and the native library kept better.
You can provide some integrated generic viewing classes like your
LDrawRenderer, but it should not be the starting point for other programmer.
> > > *** MATH CLASSES ***
> > Hm, they should be only wrapper classes to underlying native code in the
> > used language on the used system.
> Show me a vector/matrix library that is (1) an accepted standard, (2) free
> and readily available, (3) works on different systems, and (4) has hooks for
> multiple languages such as Java and Perl. I desparately wanted one,
> couldn't find one, so I implemented one. FWIW, it wasn't that big of a deal
> to implement, just some review from my school math texts.
That's not the point. I said, they shall be wrapper classes or better interfaces
for undelying code, so you can prefer your own code as underlying, but if there
is a - for the intention of the program - better lib out there, you will get
problems to include if you make the math classes a closed group.
> > The more you specify their working code
> > the more you can't use local optimizations.
>
> This raises an excellent point. The matrix library would be hammered the
> most, so clearly a way to allow any kind of 3rd-party optimizations
> (including linking in machine code) should be available. How about if we
> make Vector* and Matrix* abstract base classes, and then provide a Java (or
> Perl or Python, etc.) implementation as a baseline?
As I said: make them wrapper / interfaces. There is no obstacle to provide
a own base implementation. But don't exclude existing third parties.
Sascha
|
|
Message is in Reply To:
 | | Re: A comprehensive LDraw object model
|
| (...) The way I designed my stuff is that the code in the linetype classes manage the objects they contain -- mostly just allocation, serialization and stringification of a matrix or a list of vectors. However, any rendering or parsing behavior is (...) (23 years ago, 10-Feb-02, to lugnet.cad.dev)
|
30 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
