Miranda getPropertySlot

From Erights

(Difference between revisions)
Jump to: navigation, search
(Add Javadoc.)
(add method header)
(3 intermediate revisions not shown)
Line 1: Line 1:
'''__getPropertySlot/1''' is a deprecated [[Miranda message]].
{{instance msgdoc|__getPropertySlot|1|<var>propName</var> :[[String]]|[[Slot]]}}
==Original Javadoc==
==Original Javadoc==

Latest revision as of 03:21, 7 August 2011

__getPropertySlot/1 is a deprecated Miranda message.


Signature: __getPropertySlot(propName :String) :Slot

Original Javadoc

Used in the expansion of 'foo::bar' so that this syntax represents foo's "bar" property.

'foo::bar' expands to 'foo.__getPropertySlot("bar").get()'. When used an an lValue, 'foo::bar := newValue' expands essentially to 'foo.__getPropertySlot("bar").put(newValue)' except that the expansion also has the value of the assignment expression be the value assigned.

And finally 'foo::&bar' expands to 'foo.__getPropertySlot("bar")'

The Miranda behavior provided here synthesizes, for foo's bar property, a Slot object
  • whose 'get()' does a 'foo.getBar()'
  • whose 'put(newValue)' does a 'foo.setBar(newValue)'
  • and whose 'isFinal()' returns false</tt>'.

See also: Re: On kernel-E, operators, and properties (part 1)

Deprecated: Even if E does again decide to support explicit properties, it'll do it with a global function that asks the object's {@link #__getAllegedType} for the methods for its properties.


This protocol should probably be deprecated and removed, as it does not compose under inheritance. Thread: [1] [2]

Personal tools
more tools