On Jun 17, 11:30am, Mark Waks wrote:
> Subject: LANG: OOGL (was Re: LANG: Re: scalability (VRML))
> Mike describes how OOGL could be used in an object-oriented fashion.
> I hadn't grokked this -- I'm afraid that the OOGL docs aren't very
> clear on this point.
>
There are two books by Addison-Wesley documenting Inventor.
> I find myself biased against OOGL, and it's hard to put my finger on
> exactly why. It may simply be that I don't care for its look -- the
> syntax and choice of keywords aren't particularly intuitive, and I
> suspect that I would find it a hard language to program in. It's very,
> very concise, to the point of being hard-to-read, which makes the
> language feel a little archaic to me -- conciseness for its own sake
> is a very 1970's style of language design, and most stuff being done
> today recognizes that code clarity is far more important than size of
> source. (Heck, even Lisp is getting more verbose!)
>
Inventor is very easy to read
> On the other hand (putting on my Devil's Advocate hat for a moment),
> this may not be a telling argument. Looking at it rationally, I'm not
> actually certain that anyone is going to write this stuff by hand.
> Even HTML, a pretty simple markup language, is more and more being
> designed by people using WYSIWYG tools, instead of coded by hand. The
> odds are that almost all VRML work will be done using graphical tools,
> which will generate the resulting code. So code clarity may just not
> be an important issue.
>
Inventor is not so hard to edit by hand (I've been doing it for years).
> Its greatest strength is clear: there are already tools for
> manipulating it. This is no small advantage; it could give us several
> months' headstart on the project if we can adapt Geomview to our
> needs. It is, as I recall, more-or-less public domain, one of our
> critical needs. It's reasonably strong in graphical display, and
> presumably we could adapt it to new technologies as they come along.
> It's easy to parse, and it *is* concise, which ought to result in
> about as little bandwidth as we can get away with.
>
There are more tools for Inventor and more people using it. It is not
as consise, but we could agree on a subset of it to use. The Inventor file
format is public domain (ie: OPEN Inventor). It is available on many platforms
and it is available in both binary and ascii file formats
> On the flip side, it lacks a number of the features we've talked
> about. It really has no means of abstractly identifying objects.
> (That is, there is no way of saying, "Put a box of Kleenex there";
> you have to give a literal filename or URL.) I think we would need
> to extend it at least that far, to allow inclusion of objects
> conceptually, and allow the browser to resolve the identity of
> those objects. (Possibly an extension of the suggested "<"
> construct, giving a conceptual object name, plus a URL default.)
>
Inventor allows this to an extent through instancing. Inventor also
allows naming objects so that it would be easier to create an abstract object.
> It has no way of identifying non-graphical properties. We will
> need (in the long run) a way of at *least* attaching hooks to
> objects, so that when an action is performed on an object, we can
> pass that action on to a routine designed to deal with it. (And
> we need to deal with some hard issues of what it means to deal
> with an action -- are we calling local or remote routines?) Also,
> we'll need to add navigational constructs, so that there's a clear
> way of saying, "This is a door, and through it you can see Justin's
> office (which is at this URL)".
>
Inventor has several ways to do this.
> And God knows we need better documentation. (This isn't just a
> long-term issue -- we'll need a clearer language spec for our
> own use as we develop.)
>
see my first issue above
> But most of these are medium-term issues. I'd say that *if* we
> can consider ourselves to have a reasonable carte blanche to
> alter the language, so that we can add these things later, we
> could probably use OOGL as a starting point. We'll need to add
> a lot of additional constructs later (in particular, the concept
> of non-graphical properties), but it will probably suffice for
> the first cut...
>
I beg to differ.
> -- Justin
>
Kevin
P.S. you can get more info from Inventor from sgi
html://www.sgi.com, I think