Inconsistent referencing behavior/documentation

Hello guys,

I find that there is a fair bit of confusing/contradictory information about how
references (&) work in anybody. I have found two different (contradictory?)
explanations in the documentation and yet, the interpreter does not seem to
follow any of the two logics…

When looking at the class tree from p. 18 (Section 2.1), we see that the
AnyRefObject (p. 38) is a placeholder for any reference. In other words,
regardless of the object that is referenced, what we have is a AnyRefObject. In
practice, this is demonstrated in Anybody by double-clicking a reference object
and looking at the Object Description window.

This behavior suggests that it is of no importance what is the type of the
reference. In other words, these 5 assignment from reference would be perfectly
equivalent:

  1.   // RefFrame reference type
    
  2.   AnySeg& Ref1 = ASegObject;
    
  3.   AnyVar Mass1 = Ref1.Mass;
    
  4.   // RefFrame reference type
    
  5.   AnyRefFrame& Ref2 = ASegObject;
    
  6.   AnyVar Mass2 = Ref2.Mass;
    
  7.   // Folder reference type
    
  8. AnyFolder& Ref3 = ASegObject;

  9. AnyVar Mass3 = Ref3.Mass;

  10. // Object reference type

  11. AnyObject& Ref4 = ASegObject;

  12. AnyVar Mass4 = Ref4.Mass;

  13. // Var reference type

  14. AnyVar& Ref5 = ASegObject.Mass;

  15. AnyVar Mass5 = Ref5;

Yet, in p.8 of the documentation (section 1.3.2, last 2 paragraphs), we explain
that references are done using an Object Oriented approach. From this point of
view, restrictions should appear when the reference is NOT a descendant of
AnyFolder. This means that the assignment of line 15 would be invalid, while the
rest of the code should be valid.

Therefore, documentation p. 8 and p. 38 are in contradiction.

But this is not only a documentation problem, as it become a lot more
complicated when looking at the Anyscript interpreter behavior: in the previous
code, lines 14 and 18 are considered errors.

Line 14: AnyObject& Ref4 = ASegObject;

Error: ‘Ref4’ : Non-folder reference object declaration

Although AnySeg is derived from AnyObject (like all classes in anybody), only
folder object references are accepted. This has no root in any of the logics
described in p.8 (AnyRefObject logic) or in p.38.

Logic from AnyRefObject (p. 8) expected behavior:

Line 14 and 15 should be valid.

Logic from object oriented approach (p. 38) expected behavior:

The error should be given for line 15, not 14, and say “Mass is not a member
of AnyObject� or “AnyObject classes cannot have members�.

Line 18: AnyVar& Ref5 = ASegObjec.Mass;

Error: ‘Ref5’ : Non-folder reference object declaration

Although Mass is an AnyVar, it is impossible to make a reference to an AnyVar
using the reference operator &. In fact, even if the statement had been
AnyObject& Ref5 = ASegObject.Mass;, it would still have been invalid. Again,
this has no root in any of the logics explained in p.8 and p.38.

Logic from AnyRefObject (p.8) expected behavior:

Line 18 and 19 should be valid.

Logic from object oriented approach (p. 38) expected behavior:

Line 18 and 19 should be valid.

Note:

I am conscious that there is a AnyVarRef class that can be used to reference
AnyVars, yet, it has a very different behavior than the reference operator (&).
Therefore it does not constitute, in my mind, a valid replacement.

Note:

If you write the statement “AnyFolder& Ref = ASegObject.Mass;�, you will get
a lightly different error, which seems to come from the object oriented logic
(p.38): ‘Mass5’ : Reference to non-folder object. ‘Mass’ is of class ‘AnyVar’

Questions:

  1.   Which of the behavior (p. 8 or p.38) is the right one?
    
  2.   Is there a rationale behind the Folder only reference error, or is it
    

an artifact from previous versions?

  1.   Using the p.38 logic (object oriented), script wise, it would be rather
    

useless to have a AnyObject reference. Yet, wouldn’t be useful if you just
wanted to create shortcuts in the model tree browser?

  1.   If you plan on fixing it, what do you plan on fixing? The documentation
    

of the interpreter?

Sorry for the long e-mail and I hope I didn’t give you guys too much of a
headache!

J-O

No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.5/1356 - Release Date: 4/2/2008 4:14
PM

[Non-text portions of this message have been removed]

Hello Jean-Olivier,

That was a long one;-) I am sorry that this seems to have caused a good deal
of troubles investigating it to this extend.

I shall try to answer all your points, but I would like to do it with some
general comments, because I think this might provide a better understanding
afterwards (also for other readers).

A) References have, at least in all newer versions of AnyBody, been
restricted to AnyFolder objects - on purpose. Therefore you cannot make
reference objects pointing AnyObject, AnyVar or similar. You can only use
AnyFolder and derived classes.

The primary reason is that references to all kinds of AnyValues would be
very close to ordinary expressions, so we believe this would give a
confusing double-feature: The two things, i.e., AnyVar X=Main.x; and AnyVar&
rX=Main.x; would look very much the same but value updating could be very
different. rX would always be updated when Main.x is, whereas X is only
updated when this part of the model is used. So references to AnyValue are
not allowed to avoid this confusion.

It could be discussed (and it has been, I can promise you;-) and we have no
current plans of changing this. (if you or anybody else have a point of view
on this, we will of course be happy to hear and comment on it)

B) About type handling of Reference Objects. The type handling of the
reference in AnyScript is rather simple.

When loading it will validate that the types of the left- and right-hand
sides match, i.e. the real objects must be of the type specified for the
reference either directly or by derivation. References to reference are also
only validated against the real object.

The validation feature primarily serves for the AnyScript programmer to be
able to express restrictions on the type of objects that may enter on the
right-hand side. For instance, if you are making a joint the difference
between referring to an AnyRefFrame& and an AnySeg& is only that the latter
will be stricter in what is allowed on the right-hand side. This is
important, if you make the joint by referring to objects that are created in
code that somebody else maintains. If you really need a segment you specify
this and then I cannot change it in my part without getting an error. If you
just specify an AnyRefFrame, I can change my AnySeg Reframe for be a node
(AnyRefNode) or even a fixed reference frame.

C) You could make the AnyRefFrame& as an AnyFolder& and it would still be
found as an AnyRefFrame by the joint because the reference simply return the
real object when asked in such cases.

You can think of this as if all functionality in AnyScript objects is
virtual functions in a C++ sense.

This feature has also been discussed and the argument behind the current
functionality here is purely simplicity. When searching for object of a
given type (like the joints do and any other object with Expected Members),
the reference objects are simply returning the real objects before the type
check, so an AnyFolder& and and AnySeg& that points to an AnySeg they are
both interpreted as an AnySeg.

D) You are right that the descriptions on page 8 and 38 are misleading to
some extend. Both of them! They do not reflect what I explained about the
AnyFolder being the root for the possible reference objects. Indeed they
actually used a bad case (with AnyObject) as examples.

We will of course correct this and we sincerely appreciate that you have
brought it to our attention.

E) AnyVarRef is, as you suggest yourself, not intended as a replacement for
AnyRefObject for values. Values are, as explained above, not allowed in
reference objects to avoid confusion about evaluation updates. The AnyVarRef
is a very special value (only AnyVar, not other types or dimensionalities)
that under very special circumstances allows reverse evaluation, i.e. from
left to right instead of normal right-hand side to left. But still there is
an update process taking place an being controlled by the operations
(AnyOperation) being executed.

F) Apart from the manuals I believe it is working as intended. Parts for
this have, as I indicated above, been discussed during the development of
AnyScript but we are as always open for input from users. So if you have any
points of view, please share them, and maybe the cases that lead to pursue
this issue.

I hope I answered all you questions, at least indirectly. Otherwise, please
complain;-) It was not my intension to skip anything, but there has been
some busy days here.

Best regards,

Michael


Michael Damsgaard, AnyBody Support

<http://www.anybodytech.com> www.anybodytech.com


From: anyscript@yahoogroups.com [mailto:anyscript@yahoogroups.com] On Behalf
Of Jean-Olivier Racine
Sent: Thursday, April 03, 2008 19:07
To: Anyscript Mailing List
Subject: [AnyScript] Inconsistent referencing behavior/documentation

Hello guys,

I find that there is a fair bit of confusing/contradictory information about
how references (&) work in anybody. I have found two different
(contradictory?) explanations in the documentation and yet, the interpreter
does not seem to follow any of the two logics.

When looking at the class tree from p. 18 (Section 2.1), we see that the
AnyRefObject (p. 38) is a placeholder for any reference. In other words,
regardless of the object that is referenced, what we have is a AnyRefObject.
In practice, this is demonstrated in Anybody by double-clicking a reference
object and looking at the Object Description window.

This behavior suggests that it is of no importance what is the type of the
reference. In other words, these 5 assignment from reference would be
perfectly equivalent:

  1. // RefFrame reference type

  2. AnySeg& Ref1 = ASegObject;

  3. AnyVar Mass1 = Ref1.Mass;

  4. // RefFrame reference type

  5. AnyRefFrame& Ref2 = ASegObject;

  6. AnyVar Mass2 = Ref2.Mass;

  7. // Folder reference type

  8. AnyFolder& Ref3 = ASegObject;

  9. AnyVar Mass3 = Ref3.Mass;

  10. // Object reference type

  11. AnyObject& Ref4 = ASegObject;

  12. AnyVar Mass4 = Ref4.Mass;

  13. // Var reference type

  14. AnyVar& Ref5 = ASegObject.Mass;

  15. AnyVar Mass5 = Ref5;

Yet, in p.8 of the documentation (section 1.3.2, last 2 paragraphs), we
explain that references are done using an Object Oriented approach. From
this point of view, restrictions should appear when the reference is NOT a
descendant of AnyFolder. This means that the assignment of line 15 would be
invalid, while the rest of the code should be valid.

Therefore, documentation p. 8 and p. 38 are in contradiction.

But this is not only a documentation problem, as it become a lot more
complicated when looking at the Anyscript interpreter behavior: in the
previous code, lines 14 and 18 are considered errors.

Line 14: AnyObject& Ref4 = ASegObject;

Error: ‘Ref4’ : Non-folder reference object declaration

Although AnySeg is derived from AnyObject (like all classes in anybody),
only folder object references are accepted. This has no root in any of the
logics described in p.8 (AnyRefObject logic) or in p.38.

Logic from AnyRefObject (p. 8) expected behavior:

Line 14 and 15 should be valid.

Logic from object oriented approach (p. 38) expected behavior:

The error should be given for line 15, not 14, and say “Mass is not a member
of AnyObject” or “AnyObject classes cannot have members”.

Line 18: AnyVar& Ref5 = ASegObjec.Mass;

Error: ‘Ref5’ : Non-folder reference object declaration

Although Mass is an AnyVar, it is impossible to make a reference to an
AnyVar using the reference operator &. In fact, even if the statement had
been AnyObject& Ref5 = ASegObject.Mass;, it would still have been invalid.
Again, this has no root in any of the logics explained in p.8 and p.38.

Logic from AnyRefObject (p.8) expected behavior:

Line 18 and 19 should be valid.

Logic from object oriented approach (p. 38) expected behavior:

Line 18 and 19 should be valid.

Note:

I am conscious that there is a AnyVarRef class that can be used to reference
AnyVars, yet, it has a very different behavior than the reference operator
(&). Therefore it does not constitute, in my mind, a valid replacement.

Note:

If you write the statement “AnyFolder& Ref = ASegObject.Mass;”, you will get
a lightly different error, which seems to come from the object oriented
logic (p.38): ‘Mass5’ : Reference to non-folder object. ‘Mass’ is of class
‘AnyVar’

Questions:

  1. Which of the behavior (p. 8 or p.38) is the right one?

  2. Is there a rationale behind the Folder only reference error, or is it an
    artifact from previous versions?

  3. Using the p.38 logic (object oriented), script wise, it would be rather
    useless to have a AnyObject reference. Yet, wouldn’t be useful if you just
    wanted to create shortcuts in the model tree browser?

  4. If you plan on fixing it, what do you plan on fixing? The documentation
    of the interpreter?

Sorry for the long e-mail and I hope I didn’t give you guys too much of a
headache!

J-O

No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.5/1356 - Release Date: 4/2/2008
4:14 PM

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]

Hello Michael,

A) I understand how subtle a difference this is, but I find surprising
that you limited the syntax of the parser to prevent this. Yet, I respect
your decision because I don’t have a better argument than: maybe someone
would have found it useful one day. ;p

B) See D.

C) See D.

D) Alright, it’s a lot clearer now. In other words, reference types
should be seen as a “minimum requirement type”, not an actual type.

E) Thanks for the explanation. Is there any examples of its use in the
tutorials, that you know of?

F) Alright, sounds good to me.

Thanks for taking the time to answer all of my questions. Maybe this will
save you on support time eventually :stuck_out_tongue:

Jean-Olivier Racine

HYPERLINK "mailto:joracine@humancad.com"joracine@humancad.com

HumanCAD development team

Nexgen Ergonomics Inc.

HYPERLINK "http://www.nexgenergo.com/"http://www.nexgenergo.com/

From: anyscript@yahoogroups.com [mailto:anyscript@yahoogroups.com] On Behalf
Of AnyBody Support
Sent: Tuesday, April 08, 2008 7:02 AM
To: anyscript@yahoogroups.com
Subject: RE: [AnyScript] Inconsistent referencing behavior/documentation

Hello Jean-Olivier,

That was a long one;-) I am sorry that this seems to have caused a good deal
of troubles investigating it to this extend.

I shall try to answer all your points, but I would like to do it with some
general comments, because I think this might provide a better understanding
afterwards (also for other readers).

A) References have, at least in all newer versions of AnyBody, been
restricted to AnyFolder objects - on purpose. Therefore you cannot make
reference objects pointing AnyObject, AnyVar or similar. You can only use
AnyFolder and derived classes.

The primary reason is that references to all kinds of AnyValues would be
very close to ordinary expressions, so we believe this would give a
confusing double-feature: The two things, i.e., AnyVar X=Main.x; and AnyVar&
rX=Main.x; would look very much the same but value updating could be very
different. rX would always be updated when Main.x is, whereas X is only
updated when this part of the model is used. So references to AnyValue are
not allowed to avoid this confusion.

It could be discussed (and it has been, I can promise you;-) and we have no
current plans of changing this. (if you or anybody else have a point of view
on this, we will of course be happy to hear and comment on it)

B) About type handling of Reference Objects. The type handling of the
reference in AnyScript is rather simple.

When loading it will validate that the types of the left- and right-hand
sides match, i.e. the real objects must be of the type specified for the
reference either directly or by derivation. References to reference are also
only validated against the real object.

The validation feature primarily serves for the AnyScript programmer to be
able to express restrictions on the type of objects that may enter on the
right-hand side. For instance, if you are making a joint the difference
between referring to an AnyRefFrame& and an AnySeg& is only that the latter
will be stricter in what is allowed on the right-hand side. This is
important, if you make the joint by referring to objects that are created in
code that somebody else maintains. If you really need a segment you specify
this and then I cannot change it in my part without getting an error. If you
just specify an AnyRefFrame, I can change my AnySeg Reframe for be a node
(AnyRefNode) or even a fixed reference frame.

C) You could make the AnyRefFrame& as an AnyFolder& and it would still be
found as an AnyRefFrame by the joint because the reference simply return the
real object when asked in such cases.

You can think of this as if all functionality in AnyScript objects is
virtual functions in a C++ sense.

This feature has also been discussed and the argument behind the current
functionality here is purely simplicity. When searching for object of a
given type (like the joints do and any other object with Expected Members),
the reference objects are simply returning the real objects before the type
check, so an AnyFolder& and and AnySeg& that points to an AnySeg they are
both interpreted as an AnySeg.

D) You are right that the descriptions on page 8 and 38 are misleading to
some extend. Both of them! They do not reflect what I explained about the
AnyFolder being the root for the possible reference objects. Indeed they
actually used a bad case (with AnyObject) as examples.

We will of course correct this and we sincerely appreciate that you have
brought it to our attention.

E) AnyVarRef is, as you suggest yourself, not intended as a replacement for
AnyRefObject for values. Values are, as explained above, not allowed in
reference objects to avoid confusion about evaluation updates. The AnyVarRef
is a very special value (only AnyVar, not other types or dimensionalities)
that under very special circumstances allows reverse evaluation, i.e. from
left to right instead of normal right-hand side to left. But still there is
an update process taking place an being controlled by the operations
(AnyOperation) being executed.

F) Apart from the manuals I believe it is working as intended. Parts for
this have, as I indicated above, been discussed during the development of
AnyScript but we are as always open for input from users. So if you have any
points of view, please share them, and maybe the cases that lead to pursue
this issue.

I hope I answered all you questions, at least indirectly. Otherwise, please
complain;-) It was not my intension to skip anything, but there has been
some busy days here.

Best regards,

Michael


Michael Damsgaard, AnyBody Support

<HYPERLINK "http://www.anybodytech.com"http://www.anybodytech.com>
www.anybodytech.com


From: HYPERLINK
"mailto:anyscript%40yahoogroups.com"anyscript@yahoogroups.com
[mailto:HYPERLINK
"mailto:anyscript%40yahoogroups.com"anyscript@yahoogroups.com] On Behalf
Of Jean-Olivier Racine
Sent: Thursday, April 03, 2008 19:07
To: Anyscript Mailing List
Subject: [AnyScript] Inconsistent referencing behavior/documentation

Hello guys,

I find that there is a fair bit of confusing/contradictory information about
how references (&) work in anybody. I have found two different
(contradictory?) explanations in the documentation and yet, the interpreter
does not seem to follow any of the two logics.

When looking at the class tree from p. 18 (Section 2.1), we see that the
AnyRefObject (p. 38) is a placeholder for any reference. In other words,
regardless of the object that is referenced, what we have is a AnyRefObject.
In practice, this is demonstrated in Anybody by double-clicking a reference
object and looking at the Object Description window.

This behavior suggests that it is of no importance what is the type of the
reference. In other words, these 5 assignment from reference would be
perfectly equivalent:

  1. // RefFrame reference type

  2. AnySeg& Ref1 = ASegObject;

  3. AnyVar Mass1 = Ref1.Mass;

  4. // RefFrame reference type

  5. AnyRefFrame& Ref2 = ASegObject;

  6. AnyVar Mass2 = Ref2.Mass;

  7. // Folder reference type

  8. AnyFolder& Ref3 = ASegObject;

  9. AnyVar Mass3 = Ref3.Mass;

  10. // Object reference type

  11. AnyObject& Ref4 = ASegObject;

  12. AnyVar Mass4 = Ref4.Mass;

  13. // Var reference type

  14. AnyVar& Ref5 = ASegObject.Mass;

  15. AnyVar Mass5 = Ref5;

Yet, in p.8 of the documentation (section 1.3.2, last 2 paragraphs), we
explain that references are done using an Object Oriented approach. From
this point of view, restrictions should appear when the reference is NOT a
descendant of AnyFolder. This means that the assignment of line 15 would be
invalid, while the rest of the code should be valid.

Therefore, documentation p. 8 and p. 38 are in contradiction.

But this is not only a documentation problem, as it become a lot more
complicated when looking at the Anyscript interpreter behavior: in the
previous code, lines 14 and 18 are considered errors.

Line 14: AnyObject& Ref4 = ASegObject;

Error: ‘Ref4’ : Non-folder reference object declaration

Although AnySeg is derived from AnyObject (like all classes in anybody),
only folder object references are accepted. This has no root in any of the
logics described in p.8 (AnyRefObject logic) or in p.38.

Logic from AnyRefObject (p. 8) expected behavior:

Line 14 and 15 should be valid.

Logic from object oriented approach (p. 38) expected behavior:

The error should be given for line 15, not 14, and say “Mass is not a member
of AnyObject” or “AnyObject classes cannot have members”.

Line 18: AnyVar& Ref5 = ASegObjec.Mass;

Error: ‘Ref5’ : Non-folder reference object declaration

Although Mass is an AnyVar, it is impossible to make a reference to an
AnyVar using the reference operator &. In fact, even if the statement had
been AnyObject& Ref5 = ASegObject.Mass;, it would still have been invalid.
Again, this has no root in any of the logics explained in p.8 and p.38.

Logic from AnyRefObject (p.8) expected behavior:

Line 18 and 19 should be valid.

Logic from object oriented approach (p. 38) expected behavior:

Line 18 and 19 should be valid.

Note:

I am conscious that there is a AnyVarRef class that can be used to reference
AnyVars, yet, it has a very different behavior than the reference operator
(&). Therefore it does not constitute, in my mind, a valid replacement.

Note:

If you write the statement “AnyFolder& Ref = ASegObject.Mass;”, you will get
a lightly different error, which seems to come from the object oriented
logic (p.38): ‘Mass5’ : Reference to non-folder object. ‘Mass’ is of class
‘AnyVar’

Questions:

  1. Which of the behavior (p. 8 or p.38) is the right one?

  2. Is there a rationale behind the Folder only reference error, or is it an
    artifact from previous versions?

  3. Using the p.38 logic (object oriented), script wise, it would be rather
    useless to have a AnyObject reference. Yet, wouldn’t be useful if you just
    wanted to create shortcuts in the model tree browser?

  4. If you plan on fixing it, what do you plan on fixing? The documentation
    of the interpreter?

Sorry for the long e-mail and I hope I didn’t give you guys too much of a
headache!

J-O

No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.5/1356 - Release Date: 4/2/2008
4:14 PM

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]

No virus found in this incoming message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.9/1365 - Release Date: 4/8/2008
7:30 AM

No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 269.22.13/1377 - Release Date: 4/14/2008
9:26 AM

[Non-text portions of this message have been removed]

Hello Jean-Olivier,

I have embedded answers in your text below.

> A) I understand how subtle a difference this is, but I find surprising
> that you limited the syntax of the parser to prevent this. Yet, I respect
> your decision because I don’t have a better argument than: maybe someone
> would have found it useful one day. ;p

Somebody has already argued like that previously;-) I myself am a C++
programmer, so I fully understand your line of thought.
But on the other hand AnyScript was intended to be a simpler language than
C++, so in the view of keeping things simple, we decided like did.

If you have any ideas of where it could be useful, please let us hear about;
either directly or here on the group if you think somebody else could have
points of view.

> B) See D.
>
> C) See D.
>
> D) Alright, it’s a lot clearer now. In other words, reference types
> should be seen as a “minimum requirement type”, not an actual type.

Thanks. Yes you could say “minimum requirement type”.
I shall do my best to transfer this clearness to the AnyScript manual.
Maybe I will borrow your phrase “minimum requirement type” in the
explanation.

> E) Thanks for the explanation. Is there any examples of its use in
> the
> tutorials, that you know of?

No I do not think so. The AnyVarRef was not originally aimed at the
AnyScript users, but more for internal use. It is used in AnyDesVar for the
design variable itself (so to speak), because the design variable needs to
get initial values from the actual design variable (AnyFloat) in the model
but also to transfer back values to this when doing design updates.

I do not know how you could exploit this from the AnyScript only, because
you need some operation to transfer the values back.
You can do this by AnyDesVar in AnyDesStudy derived classes. They might do
the tricks you are aiming at.

Again - let us know what you have in mind…
Maybe it can lead something of general use.

> F) Alright, sounds good to me.
>
> Thanks for taking the time to answer all of my questions. Maybe this will
> save you on support time eventually :stuck_out_tongue:

You are more than welcome. It is really nice that users start to digging
this deep, I think. And indeed it was our misleading descriptions that put
you of track - sorry for that and it will nice to fix this.

Best regards,

Michael

Michael Damsgaard, AnyBody Support

>
> Jean-Olivier Racine
>
> HYPERLINK "mailto:joracine@humancad.com"joracine@humancad.com
>
> HumanCAD development team
>
> Nexgen Ergonomics Inc.
>
> HYPERLINK "http://www.nexgenergo.com/"http://www.nexgenergo.com/
>
>
>
> From: anyscript@yahoogroups.com [mailto:anyscript@yahoogroups.com] On
> Behalf
> Of AnyBody Support
> Sent: Tuesday, April 08, 2008 7:02 AM
> To: anyscript@yahoogroups.com
> Subject: RE: [AnyScript] Inconsistent referencing behavior/documentation
>
>
>
> Hello Jean-Olivier,
>
> That was a long one;-) I am sorry that this seems to have caused a good
> deal
> of troubles investigating it to this extend.
>
> I shall try to answer all your points, but I would like to do it with some
> general comments, because I think this might provide a better
> understanding
> afterwards (also for other readers).
>
> A) References have, at least in all newer versions of AnyBody, been
> restricted to AnyFolder objects - on purpose. Therefore you cannot make
> reference objects pointing AnyObject, AnyVar or similar. You can only use
> AnyFolder and derived classes.
>
> The primary reason is that references to all kinds of AnyValues would be
> very close to ordinary expressions, so we believe this would give a
> confusing double-feature: The two things, i.e., AnyVar X=Main.x; and
> AnyVar&
> rX=Main.x; would look very much the same but value updating could be very
> different. rX would always be updated when Main.x is, whereas X is only
> updated when this part of the model is used. So references to AnyValue are
> not allowed to avoid this confusion.
>
> It could be discussed (and it has been, I can promise you;-) and we have
> no
> current plans of changing this. (if you or anybody else have a point of
> view
> on this, we will of course be happy to hear and comment on it)
>
> B) About type handling of Reference Objects. The type handling of the
> reference in AnyScript is rather simple.
>
> When loading it will validate that the types of the left- and right-hand
> sides match, i.e. the real objects must be of the type specified for the
> reference either directly or by derivation. References to reference are
> also
> only validated against the real object.
>
> The validation feature primarily serves for the AnyScript programmer to be
> able to express restrictions on the type of objects that may enter on the
> right-hand side. For instance, if you are making a joint the difference
> between referring to an AnyRefFrame& and an AnySeg& is only that the
> latter
> will be stricter in what is allowed on the right-hand side. This is
> important, if you make the joint by referring to objects that are created
> in
> code that somebody else maintains. If you really need a segment you
> specify
> this and then I cannot change it in my part without getting an error. If
> you
> just specify an AnyRefFrame, I can change my AnySeg Reframe for be a node
> (AnyRefNode) or even a fixed reference frame.
>
> C) You could make the AnyRefFrame& as an AnyFolder& and it would still be
> found as an AnyRefFrame by the joint because the reference simply return
> the
> real object when asked in such cases.
>
> You can think of this as if all functionality in AnyScript objects is
> virtual functions in a C++ sense.
>
> This feature has also been discussed and the argument behind the current
> functionality here is purely simplicity. When searching for object of a
> given type (like the joints do and any other object with Expected
> Members),
> the reference objects are simply returning the real objects before the
> type
> check, so an AnyFolder& and and AnySeg& that points to an AnySeg they are
> both interpreted as an AnySeg.
>
> D) You are right that the descriptions on page 8 and 38 are misleading to
> some extend. Both of them! They do not reflect what I explained about the
> AnyFolder being the root for the possible reference objects. Indeed they
> actually used a bad case (with AnyObject) as examples.
>
> We will of course correct this and we sincerely appreciate that you have
> brought it to our attention.
>
> E) AnyVarRef is, as you suggest yourself, not intended as a replacement
> for
> AnyRefObject for values. Values are, as explained above, not allowed in
> reference objects to avoid confusion about evaluation updates. The
> AnyVarRef
> is a very special value (only AnyVar, not other types or dimensionalities)
> that under very special circumstances allows reverse evaluation, i.e. from
> left to right instead of normal right-hand side to left. But still there
> is
> an update process taking place an being controlled by the operations
> (AnyOperation) being executed.
>
> F) Apart from the manuals I believe it is working as intended. Parts for
> this have, as I indicated above, been discussed during the development of
> AnyScript but we are as always open for input from users. So if you have
> any
> points of view, please share them, and maybe the cases that lead to pursue
> this issue.
>
> I hope I answered all you questions, at least indirectly. Otherwise,
> please
> complain;-) It was not my intension to skip anything, but there has been
> some busy days here.
>
> Best regards,
>
> Michael
>
> ------------------------------
>
> Michael Damsgaard, AnyBody Support
>
> <HYPERLINK "http://www.anybodytech.com"http://www.anybodytech.com>
> www.anybodytech.com
>
> _____
>
> From: HYPERLINK
> "mailto:anyscript%40yahoogroups.com"anyscript@yahoogroups.com
> [mailto:HYPERLINK
> "mailto:anyscript%40yahoogroups.com"anyscript@yahoogroups.com] On Behalf
> Of Jean-Olivier Racine
> Sent: Thursday, April 03, 2008 19:07
> To: Anyscript Mailing List
> Subject: [AnyScript] Inconsistent referencing behavior/documentation
>
> Hello guys,
>
> I find that there is a fair bit of confusing/contradictory information
> about
> how references (&) work in anybody. I have found two different
> (contradictory?) explanations in the documentation and yet, the
> interpreter
> does not seem to follow any of the two logics.
>
> When looking at the class tree from p. 18 (Section 2.1), we see that the
> AnyRefObject (p. 38) is a placeholder for any reference. In other words,
> regardless of the object that is referenced, what we have is a
> AnyRefObject…
> In practice, this is demonstrated in Anybody by double-clicking a
> reference
> object and looking at the Object Description window.
>
> This behavior suggests that it is of no importance what is the type of the
> reference. In other words, these 5 assignment from reference would be
> perfectly equivalent:
>
> 1. // RefFrame reference type
>
> 2. AnySeg& Ref1 = ASegObject;
>
> 3. AnyVar Mass1 = Ref1.Mass;
>
> 4.
>
> 5. // RefFrame reference type
>
> 6. AnyRefFrame& Ref2 = ASegObject;
>
> 7. AnyVar Mass2 = Ref2.Mass;
>
> 8.
>
> 9. // Folder reference type
>
> 10. AnyFolder& Ref3 = ASegObject;
>
> 11. AnyVar Mass3 = Ref3.Mass;
>
> 12.
>
> 13. // Object reference type
>
> 14. AnyObject& Ref4 = ASegObject;
>
> 15. AnyVar Mass4 = Ref4.Mass;
>
> 16.
>
> 17. // Var reference type
>
> 18. AnyVar& Ref5 = ASegObject.Mass;
>
> 19. AnyVar Mass5 = Ref5;
>
> Yet, in p.8 of the documentation (section 1.3.2, last 2 paragraphs), we
> explain that references are done using an Object Oriented approach. From
> this point of view, restrictions should appear when the reference is NOT a
> descendant of AnyFolder. This means that the assignment of line 15 would
> be
> invalid, while the rest of the code should be valid.
>
> Therefore, documentation p. 8 and p. 38 are in contradiction.
>
> But this is not only a documentation problem, as it become a lot more
> complicated when looking at the Anyscript interpreter behavior: in the
> previous code, lines 14 and 18 are considered errors.
>
> Line 14: AnyObject& Ref4 = ASegObject;
>
> Error: ‘Ref4’ : Non-folder reference object declaration
>
> Although AnySeg is derived from AnyObject (like all classes in anybody),
> only folder object references are accepted. This has no root in any of the
> logics described in p.8 (AnyRefObject logic) or in p.38.
>
> Logic from AnyRefObject (p. 8) expected behavior:
>
> Line 14 and 15 should be valid.
>
> Logic from object oriented approach (p. 38) expected behavior:
>
> The error should be given for line 15, not 14, and say “Mass is not a
> member
> of AnyObject” or “AnyObject classes cannot have members”.
>
> Line 18: AnyVar& Ref5 = ASegObjec.Mass;
>
> Error: ‘Ref5’ : Non-folder reference object declaration
>
> Although Mass is an AnyVar, it is impossible to make a reference to an
> AnyVar using the reference operator &. In fact, even if the statement had
> been AnyObject& Ref5 = ASegObject.Mass;, it would still have been
> invalid…
> Again, this has no root in any of the logics explained in p.8 and p.38.
>
> Logic from AnyRefObject (p.8) expected behavior:
>
> Line 18 and 19 should be valid.
>
> Logic from object oriented approach (p. 38) expected behavior:
>
> Line 18 and 19 should be valid.
>
> Note:
>
> I am conscious that there is a AnyVarRef class that can be used to
> reference
> AnyVars, yet, it has a very different behavior than the reference operator
> (&). Therefore it does not constitute, in my mind, a valid replacement.
>
> Note:
>
> If you write the statement “AnyFolder& Ref = ASegObject.Mass;”, you will
> get
> a lightly different error, which seems to come from the object oriented
> logic (p.38): ‘Mass5’ : Reference to non-folder object. ‘Mass’ is of class
> ‘AnyVar’
>
> Questions:
>
> 1. Which of the behavior (p. 8 or p.38) is the right one?
>
> 2. Is there a rationale behind the Folder only reference error, or is it
> an
> artifact from previous versions?
>
> 3. Using the p.38 logic (object oriented), script wise, it would be rather
> useless to have a AnyObject reference. Yet, wouldn’t be useful if you just
> wanted to create shortcuts in the model tree browser?
>
> 4. If you plan on fixing it, what do you plan on fixing? The documentation
> of the interpreter?
>
> Sorry for the long e-mail and I hope I didn’t give you guys too much of a
> headache!
>
> J-O
>
> No virus found in this outgoing message.
> Checked by AVG.
> Version: 7.5.519 / Virus Database: 269.22.5/1356 - Release Date: 4/2/2008
> 4:14 PM
>
> [Non-text portions of this message have been removed]
>
> [Non-text portions of this message have been removed]
>
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.519 / Virus Database: 269.22.9/1365 - Release Date: 4/8/2008
> 7:30 AM
>
>
> No virus found in this outgoing message.
> Checked by AVG.
> Version: 7.5.524 / Virus Database: 269.22.13/1377 - Release Date:
> 4/14/2008
> 9:26 AM
>
>
>
> [Non-text portions of this message have been removed]
>
>
> ------------------------------------
>
> Users of the AnyBody Modeling System help each other create biomechanical
> models in the AnyScript language.Yahoo! Groups Links
>
>
>