Miranda getPropertySlot

From Erights

(Difference between revisions)
Jump to: navigation, search
(link to non-composability issue)
(add method header)
 
Line 1: Line 1:
 +
'''__getPropertySlot/1''' is a deprecated [[Miranda message]].
 +
 +
{{instance msgdoc|__getPropertySlot|1|<var>propName</var> :[[String]]|[[Slot]]}}
 +
 +
==Original Javadoc==
 +
 +
Used in the expansion of '<tt>foo::bar</tt>' so that this syntax
 +
represents foo's "bar" property.
 +
 +
'<tt>foo::bar</tt>' expands to '<tt>foo.__getPropertySlot("bar").get()</tt>'.
 +
When used an an lValue, '<tt>foo::bar := newValue</tt>' expands
 +
essentially to '<tt>foo.__getPropertySlot("bar").put(newValue)</tt>'
 +
except that the expansion also has the value of the assignment
 +
expression be the value assigned.
 +
 +
And finally '<tt>foo::&bar</tt>' expands to '<tt>foo.__getPropertySlot("bar")</tt>'
 +
<p><hr> The Miranda behavior provided here synthesizes, for foo's bar
 +
property, a Slot object <ul> <li>whose '<tt>get()</tt>' does a
 +
'<tt>foo.getBar()</tt>' <li>whose '<tt>put(newValue)</tt>' does a
 +
'<tt>foo.setBar(newValue)</tt>' <li>and whose '<tt>isFinal()</tt>'
 +
returns false</tt>'. </ul>
 +
 +
See also: [http://www.eros-os.org/pipermail/e-lang/2004-April/009720.html 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.
 +
 +
== Issues ==
== Issues ==
This protocol should probably be deprecated and removed, as it does not compose under inheritance. Thread: [http://www.eros-os.org/pipermail/e-lang/2005-December/thread.html#11042] [http://www.eros-os.org/pipermail/e-lang/2006-January/thread.html#11064]
This protocol should probably be deprecated and removed, as it does not compose under inheritance. Thread: [http://www.eros-os.org/pipermail/e-lang/2005-December/thread.html#11042] [http://www.eros-os.org/pipermail/e-lang/2006-January/thread.html#11064]
-
[[Category:Open issues]]
+
[[Category:Miranda messages]]
 +
[[Category:Unresolved design issues]]

Latest revision as of 03:21, 7 August 2011

__getPropertySlot/1 is a deprecated Miranda message.

__getPropertySlot/1

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.


Issues

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

Personal tools
more tools