Setting a property vs calling a property's method

Find out why the . goes before the /

Moderator: Paul Tuersley

Post Reply
davestewart
Posts: 114
Joined: March 10th, 2005, 5:50 am
Location: London, UK
Contact:

Maybe I'm missing something, but does anyone know why Adobe have chosen to have properties set by calling a method of a property, as opposed to just setting the property's value?

object.property.setValue(value)
vs
object.property.value=value

Property expressions are read/write... why not property values?

Dave
Paul Tuersley
Posts: 704
Joined: June 5th, 2004, 7:59 am
Location: London, UK

Well you can also do:

setValueAtKey(keyframe, value)
setValueAtTime(time, value)
setValuesAtTimes(arrayOfTimes, arrayOfValues)

So presumably it's done this way for consistency. As for expressions, firstly they aren't property values and secondly, none of the above methods would apply to expressions so I guess it's not that strange they should be treated differently.

Paul T
davestewart
Posts: 114
Joined: March 10th, 2005, 5:50 am
Location: London, UK
Contact:

Some fair points raised there. But if we're talking consistency - what about consistency with ECMA standards? Maybe it's because of the architecture of a "property" (ie with keyframes and such like) rather than a "value".

If anyone knows for sure, be sure to chip in,
Cheers,
Dave
vidpat
Posts: 86
Joined: October 21st, 2004, 12:36 am
Location: Phoenix, AZ
Contact:

It is not uncommon for accessors and mutators to be implemented as functions even in languages that support properties. Although not necessary, perhaps Adobe chose this approach for consistency with user objects. Properties of user objects ("Function Objects" in the ECMAScript spec) are really just members in the function scope. Unlike user objects, I believe native and host objects' properties can have handlers and access attributes. User object properties do not have this, so there is no mechanism for retrieving or adding data to an internal data structure, bounds checking, type checking, or conversion of data representation when accessing or assigning to properties.

For example, consider a user object that represents time. The object stores time data as a single integer value representing seconds elapsed. If that value is visible property of the object, a user could assign a string formatted as SMPTE style time to the property without incident. The data property of the object now contains a string, not an integer representation. Thus, when a member function of the object is called to add 10 seconds to the time, it fails or succeeds incorrectly because the internal state is not of the correct type. In this case, the data should be kept private and accessor and mutator functions should be provided to get and set the time in a format other than its internal representation.

In some languages, like C#, properties have handlers which are called on access or assignment. In ECMAScript, however, a property's data should best be an object, rather than a primitive type. Additionally, the parent must not rely on persistance of the property's state.

{
As an aside, I happened to note that the ECMAScript spec states that there is no block scope, only global and function scope. So, according to the spec, the curly-brackets we've been wrapping our scripts in shouldn't keep it out of the global scope. Then again, it doesn't hurt.
}

Well, that's my take. I apologize for the lengthy discursion, but I found the question interesting.

Peter
davestewart
Posts: 114
Joined: March 10th, 2005, 5:50 am
Location: London, UK
Contact:

Thanks Peter; yeah, it had me thinking... and thanks for the very clued-up reply!

My reason for asking was that in DHTML and ActionScript most properties are assigned straight. In AE you can assign simple things like time, comp.name, etc directly. I guess there must be some type-checking issue with directly assigning values to animatable properties themselves because of the internal structure. However read/write values still seems a more 'natural' way to program than having to call methods. Maybe they'll add the functionality next release.

Regarding variables and block scope - yup, I always keep em unique and pre-declare where ever possible. Nothing too sophisticated regarding scoping in JS eh ;)

Keep 'em coming,
Cheers,
Dave
Dan Ebberts
Posts: 320
Joined: June 26th, 2004, 10:01 am
Location: Folsom, CA
Contact:

I think most of the key points have been mentioned, but let me contribute my simplified summary.

Part of the confusion stems from 'propertry' not meaning the same thing in AE scripting as it does in JavaScript. I think this is because layers had 'properties' before AE had scripting. In AE, a property is an object that represents the value of an effect or layer transform that can be animated. As previously mentioned, properties have their own methods to set and retrieve values and keys at specific times.

AE scripting uses the term 'attribute' to refer to what JavaScript calls 'properties'. They're not objects and they can't be animated, so a simple assignment operation is all that's needed to set the value. A blending mode is a good example of an attribute.

So, in general, if you can animate it, it's a property - if you can't, it's an attribute.

That's my theory anyway :-)

Dan
davestewart
Posts: 114
Joined: March 10th, 2005, 5:50 am
Location: London, UK
Contact:

Your explanation of proerties and attributes, and the methods of setting their values makes perfect sense; thanks.

If anyone from the After Effects scripting develpment team is reading this:
Can you let setValue work on pre-animated properties please?

Ta.
Post Reply