Miranda getPropertySlot - Revision history

Kevin Reid: add method header

Kevin Reid — Sun, 07 Aug 2011 03:21:09 GMT

add method header

New page

'''__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 ==

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:Miranda messages]]
[[Category:Unresolved design issues]]

Kevin Reid: Add Javadoc.

Kevin Reid — Sun, 07 Aug 2011 03:19:27 GMT

Add Javadoc.

←Older revision		Revision as of 03:19, 7 August 2011
Line 1:		Line 1:
		+	==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 ==

Kevin Reid: +cat Miranda messages

Kevin Reid — Wed, 10 Jun 2009 15:41:06 GMT

+cat Miranda messages

←Older revision		Revision as of 15:41, 10 June 2009
Line 3:		Line 3:
	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:Miranda messages]]
	[[Category:Unresolved design issues]]		[[Category:Unresolved design issues]]

Kevin Reid: recat

Kevin Reid — Wed, 02 Jul 2008 02:27:06 GMT

recat

←Older revision		Revision as of 02:27, 2 July 2008
Line 3:		Line 3:
	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:Unresolved design issues]]

Kevin Reid: link to non-composability issue

Kevin Reid — Sat, 21 Apr 2007 19:37:31 GMT

link to non-composability issue

←Older revision		Revision as of 19:37, 21 April 2007
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:~~Miranda messages]]~~	+	[[Category:Open issues]]
-	~~[[Category:Unresolved design~~ issues]]	+