Dumb Newbie Questions -- 1 of N

[Richmond Mathewson]

Maybe my problem comes from taking the computer programming metaphor a 
bit too literally.

I think of properties as things that inhere in objects, some being 
necessary and some being
contingent; rather like people with functioning lungs (necessary) and 
ideas (contingent).

Now it seems that with 'custom property' I am expected to imagine 
objects that inhere in
other objects (e.g. stacks in custom properties).

Of course, once one abandons the standard metaphor and views custom 
properties as
pointers to drawers in a filing cabinet (or, even, maybe, the drawers 
themselves) everything
becomes clearer.

The term 'custom property' is misleading; it is like asking "Where is 
Axminster?" and then
wondering why they don't show you the bathroom.

Mark Swindell wrote:
> While "property" might not be the best name, I can't think of a name 
> better suited, since  custom properties are persistent across 
> sessions,  proprietary to an object, and the syntax is consistent with 
> other object properties...  the height, the width, the visible, the 
> cpWhatEver of button x.  It seems pretty simple and straightforward.  
> What isn't intuitive is that a custom property can contain a stack, 
> for example.  Cool, but not intuitive.   I mostly use them to keep 
> variable contents or states  alive across sessions.
>
> Mark
>
>
> On May 1, 2009, at 12:29 PM, Joe Lewis Wilkins wrote:
>
>> Richmond,
>>
>> I may be all wet, but it seems to me that this custom Property thing 
>> is just Rev's way of saying you are able to provide a pointer/handle 
>> to some address in memory where all of the stuff you've put into it 
>> may be accessed, and do so rather easily. I said I didn't like the 
>> name, but that's not going to change, so??? I agree that the word 
>> "property" provides a totally different mindset.
>>
>> Joe Wilkins
>>
>> On May 1, 2009, at 12:16 PM, Richmond Mathewson wrote:
>>
>>> Maybe I'm having conceptual problems, but a custom
>>> property looks awfully like another container (such as a
>>> variable or a field) rather than a property as such.
>>>
>>> I realise that a custom property can be used as a data-source
>>> more rapidly than a field because it doesn't come with all
>>> the 'trappings' of an object. However, what is not clear to me
>>> is whether I can access data stored in the custom property
>>> of an object from a script in another, rather like the way I can
>>> access data stored in a field on a different card to the one
>>> I am 'calling' from.
>>>
>>> Peter Alcibiades wrote:
>>>> It would be nice to hear from Judy again.  Did any of these 
>>>> explanations
>>>> help?  And did you try using a custom property, and did it work?
>>>>
>>>> Peter
>>
>>
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your 
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>