The users have to have it as easy as possible. The user has to "get
it" righ away, the user has to have the confidence that what works in
some way will *always* work the same way. It has the be simple. It has
to be reliable. The user must NEVER ask if I use this feature, will
the thing break apart? Surely not. Here "subtleties" and "essence" are
concepts of no pertinence.
Easier for the end-user generally means more work for the programmer.
And yes, at some points there has to be some trade offs if you want to
offer multiple languages, unfortunately. Speed? Please, no. Any
scripting language is slow, if speed really is an issue, than one
should not go with a scripting language in the first place, as there
is a much faster API available in XSI.
So if all languages support multi-dimensional arrays and one or two of
them can use them but not the other, then it's not acceptable. If one
support output arguments but two others do not, then it's not
acceptable. If one languages nicely stranslates logic callbacks into
text streams but the others do not, then it's not acceptable.
Everything has to work the same way (using the smallest common
denominator), no matter the context. Otherwise it's an unfinished
product. If Softimage wants to offer options to the user it's fine
(although I think it has always been a big mistake in the first
place), however Softimage has to deal with the consequences: its API
has to be consistent accross all options. The end user must NEVER
suffer from such decisions. In the case of multi-dimensional arrays I
think amazingly ridiculous.
I'm really sorry if I'm sounding offending and obtuse to
hard-labouring programmers at Softimage, that really is not the
intention. But as a hard-labouring scripter myself I don't see why I
should accept to be stuffed with condescending explanations about
Martians to explain that things were not done properly. If I told my
superior that users here can't use my tools because they're
left-handed I'd be told to fix it right away.
On 3/22/07, Thomas Kang <grafica(at)gmail.com> wrote:
> This gets into how the data is structured internally, and how that data then
> gets shuttled through the Microsoft's ActiveScripting interface, and how
> JScript doesn't quite have the facilities to support those constructs
> transparently. Basically, the limitations of the common data interface and
> the languages are forcing the variations in the way data gets accessed.
>
> Take a word in German like "Zeitgeist". It translates roughly to "spirit of
> the times", but something gets lost in that translation and it fails to
> capture the full essence of that word. Let's now say that there's a Martian
> who has started learning English via the newly started Berlitz "English for
> Martians" language training program, but no such course has begun yet for
> German. So when this Martian encounters the German word "Zeitgeist", he
> (she? it?) translates it first to English by going to a bookstore and
> looking it up in an English-German dictionary, then translates the English
> word to Martian mentally. However, let's say that there's actually a word
> in Martian that maps really nicely to Zeitgeist, which is "aaaaa".
> Unfortunately, because the translation had to go through English, it got
> translated to "qqqqq" instead, which is a more literal translation. So the
> presence of aaaaa in the Martian language, which is a more efficient
> translation, was wasted. Now, if the Martian were sharp and enterprising,
> he would realize that qqqqq is very suggestive of aaaaa, and he might do
> some investigating on the word to realize that in fact aaaaa was the better
> match, and he would then know to translate Zeitgeist to aaaaa from then on.
> However, that's an expensive extra step he had to incur.
>
> In the meantime, let's say that there's also a Frenchman who's learning
> English, and he also encounters the word Zeitgeist. Fortunately, the
> bookstore has a French-German dictionary, so he's able to get the optimal
> translation as determined by French-German bilingual scholars who have
> studied this issue and bypass English entirely. Should we, in the interest
> of consistency, instead force the Frenchman to translate through English and
> get a literal translation as well? (Of course, this is where the example
> falls apart, because the best French translation of Zeitgeist is probably a
> literal translation just like English, maybe something like "esprit du
> temps"... but hopefully you get the point.)
>
> In this example, German is the internal data structure, the bookstore is the
> ActiveScripting interface, German -> English -> Martian is JScript's
> limitation in the mapping that forces the array to get flattened, and German
> -> French is VBScript's more native mapping directly into its
> multidimensional array structure.
>
> I hope this makes sense.
>
> Cheers,
>
> Thomas
>
>
> On 3/22/07, Bernard Lebel <3dbernard(at)gmail.com > wrote:
> > Then why not return a flat array altogether to all languages? That
> > would make much more sense.
> >
> >
> > Bernard
> >
> >
> >
> > On 3/22/07, Thomas Kang <grafica(at)gmail.com> wrote:
> > > Hi, Bernard. Re-wrapping an array into a multidimensional array is
> slow,
> > > memory-intensive, and easy to do w/ a custom function if you really want
> it
> > > (as you said you've done). Also, flattening an array and hacking the
> index
> > > computation is a familiar construction in C, so it's not as ugly as you
> > > think. I actually think it's nicer than the cringe-inducing quadruply
> > > nested loops that I sometimes see. In any case, as a programmer, I'd
> rather
> > > have the flat array, because then I can choose to take the performance
> hit
> > > and re-wrap it if I want to. The performance-consistency tradeoff is a
> > > familiar one in programming, along with performance-memory. Different
> > > languages balance them in different ways.
> > >
> > > - Thomas
> > >
> > >
> > >
> > > On 3/22/07, Bernard Lebel <3dbernard(at)gmail.com> wrote:
> > > > I understand it's a language thing. But I don't understand why isn't
> > > > anyone at Softimage working something to make things transparent. I
> > > > mean I've written my own function to "re-wrap" the flat array into a
> > > > multi-dimensional one. Why I am flamed for asking for consistency?
> > > >
> > > > I don't think my request is unreasonable.
> > > >
> > > >
> > > >
> > > >
> > > > On 3/22/07, Kim Aldis <XSI(at)kim-aldis.co.uk > wrote:
> > > > > It's not a Softimage problem. It's a language problem. You'll need
> to
> > > beat
> > > > > up on Microsoft. Or probably Sun since Sun gave MS a hard time about
> > > heading
> > > > > off into all sorts of odd Microsoft type directions with jscript.
> > > Personally
> > > > > I'd blame Microsoft, since they've done their usual trick of
> > > re-inventing
> > > > > the wheel but giving it 37 sides and 4 axles. And their version of
> the
> > > wheel
> > > > > doesn't go round and round, it's better than that. And it won't fit
> on
> > > > > anyone else's axle because Microsoft axles are better. Nor will it
> fit
> > > > > anyone else's wagon, come to that. But then they re-invented the
> wagon
> > > too.
> > > > > Made a better one that stopped people breaking it by putting things
> in
> > > back
> > > > > and attaching horses and stuff to it. Now there's an idea; we need a
> new
> > > > > horse. They could make one that'll take wheels. Not round wheels. Or
> > > even
> > > > > their own wheels. It'll need sp. Special horse wheels. And the new
> > > special
> > > > > horse wheels will need a new type of horse. And they'll need to nail
> the
> > > > > horse and the wagon down so pesky wagon drivers don't start moving
> them
> > > > > down roads and things.
> > > > >
> > > > > (dribble)
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM] On
> > > > > > Behalf Of Bernard Lebel
> > > > > > Sent: 22 March 2007 15:30
> > > > > > To: XSI(at)Softimage.COM
> > > > > > Subject: Re: How do people deal with "Elements"-like arrays in
> > > JScript?
> > > > > >
> > > > > > No I'm sorry but all SDK features and examples should work the
> same
> > > > > > way in all supported language when possible. I can hardly believe
> this
> > > > > > case has been left unhandled for so long. Does anyone at Softimage
> > > > > > care to finish the thing?
> > > > > >
> > > > > >
> > > > > > Bernard
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 3/22/07, André Adam < a_adam(at)49games.de > wrote:
> > > > > > > Naah, arrays with multiple dimensions are ugly, because you need
> > > > > > > multiple for-cycles to do the very same thing you can do like
> this
> > > > > > with
> > > > > > > a single cycle... I actually find it pretty elegant! :)
> > > > > > >
> > > > > > > -André
> > > > > > >
> > > > > > >
> > > > > > > Bernard Lebel wrote:
> > > > > > > > Ish, that is ugly :-)
> > > > > > > >
> > > > > > > >
> > > > > > > > Thanks!
> > > > > > > > Bernard
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On 3/22/07, André Adam < a_adam(at)49games.de > wrote:
> > > > > > > >> Flattening the array is completely ok; that would look like
> this:
> > > > > > > >>
> > > > > > > >> var aVCArray = new VBArray(
> oVCProp.Elements.Array).toArray();
> > > > > > > >> for(i=0; i<aVC.length; i+=4){
> > > > > > > >> aVC[i] = oRed;
> > > > > > > >> aVC[i+1] = oGreen;
> > > > > > > >> aVC[i+2] = oBlue;
> > > > > > > >> aVC[i+3] = oAlpha;
> > > > > > > >> }
> > > > > > > >>
> > > > > > > >> Hope that helps, cheers!
> > > > > > > >>
> > > > > > > >> -André
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> Bernard Lebel wrote:
> > > > > > > >> > A topic as old as time itself. Since I was already a Python
> > > user
> > > > > > when
> > > > > > > >> > I started to deal with arrays in XSI I never had to worry
> about
> > > > > > > >> > JScript/XSI shortcomings in this area.
> > > > > > > >> >
> > > > > > > >> > But now I have to use JScript.
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> > So if you get the Elements property of an object, as in
> > > > > > > >> > ClusterProperty.Elements, how do you keep separate the sub-
> > > > > > arrays?
> > > > > > > >> > (ie, avoid using VBArray which flattens everything)
> > > > > > > >> >
> > > > > > > >> > Let say I have a vertexcolor cluster property, and I want
> to
> > > > > > loop over
> > > > > > > >> > all four Elements sub-arrays at the same time, how can I do
> > > > > > that?
> > > > > > > >> >
> > > > > > > >> > Any pointer welcome.
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> > Thanks
> > > > > > > >> > Bernard
> > > > > > >
> > > > > > > ---
> > > > > > > Unsubscribe? Mail Majordomo(at)Softimage.COM with the following
> text in
> > > > > > body:
> > > > > > > unsubscribe xsi
> > > > > > >
> > > > > >
> > > > > > ---
> > > > > > Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text
> in
> > > > > > body:
> > > > > > unsubscribe xsi
> > > > >
> > > > >
> > > > > ---
> > > > > Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in
> > > body:
> > > > > unsubscribe xsi
> > > > >
> > > >
> > > > ---
> > > > Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in
> body:
> > > > unsubscribe xsi
> > > >
> > >
> > >
> >
> > ---
> > Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
> > unsubscribe xsi
> >
>
>
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
