Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Newer
Older
100644 252 lines (179 sloc) 10.224 kb
8a66b8f @ayardley 'Updated 'parrot.github.com'
ayardley authored
1 # Copyright (C) 2001-2012, Parrot Foundation.
2
3 =pod
4
5 =head1 NAME
6
7 docs/dev/pmc_obj_design_meeting_notes.pod
8
9 =head1 DESCRIPTION
10
11 This document sets out PMC/Object Design Meeting Notes which took place in
12 Chicago in 2006.
13
14 =head1 PARROT PMC/OBJECT DESIGN MEETING NOTES
15
16 During the Chicago Hackathon 2006, Jerry Gay, Matt Diephouse, chromatic,
17 Leo Toetch, Jonathan Worthington and Chip Salzenberg (arriving late) met to
18 discuss problems and proposed solutions for Parrot PMCs and objects. Previous
19 to the meeting, wiki pages were set up to gather a list of problems, they can
20 be found at L<http://rakudo.org/hackathon-chicago/index.cgi?object> and
21 L<http://rakudo.org/hackathon-chicago/index.cgi?pmc>. A log of the discussion
22 that took place can be found at
23 L<http://www.parrotcode.org/misc/parrotsketch-logs/irclog.parrotsketch-200611/irclog.parrotsketch.20061112>.
24
25 This summary has been compiled from these sources and from other
26 conversations which were not recorded.
27
28 =head2 List of problems and proposed solutions for PMCs:
29
30 =over 4
31
32 =item Not all PMCs properly serialize properties by calling the default
33 implementation
34
35 This is one of many troubles with properties. Also, properties were invented
36 at a time when it looked like Perl 6 needed them, however this suspected use
37 case has so far proven incorrect. A general property system means every PMC
38 might get properties at runtime, so all PMCs share the burden all the time of
39 an uncommonly-used "feature". Furthermore, a property as currently
40 implemented is one full-blown hash per object, typically to store a single
41 value. The same effect can easily be achieved by using one AddrRegistry Hash
42 to store values in it. Finally, if some class system needs properties, it can
43 implement it itself.
44
45 B<Recommendation>: Deprecate property support in PMCs. We may put them back
46 in later, but if we do, it will be for a good reason.
47
48 Allison: What is the proposed alternate strategy for altering the
49 attribute structure of an object at runtime? I'm still not in favor of
50 removing properties. The distinction isn't a high-level one, it's a
51 low-level implementation distinction. Would it help if we call them
52 "static attributes" and "dynamic attributes"?
53
54 =item Attributes use external data slot (pmc_ext)
55
56 When attributes are used on a PMC, they are stored in the single external
57 data segment associated with a PMC. This prevents the use of attributes and
58 storage of non-attribute data in the PMC external data segment, limiting
59 their usefulness to all but the most simple PMC types.
60
61 B<Recommendation>: Implement differently-sized PMCs. The proposed
62 pddXX_pmc.pod has been reviewed, and the implementation of a prototype
63 solution has been requested. Work on this prototype is targeted to begin
64 in trunk after the 0.4.7 release.
65
66 Allison: Agreed.
67
68 =item DYNSELF is the common case, but the common case should be SELF
69
70 The DYNSELF macro is closer to the true OO concept of 'self'; if anything is
71 worthy of the name SELF, it is DYNSELF. DYNSELF does dispatching, while SELF
72 statically calls the method in the current class.
73
74 B<Recommendation>: Throughout the source, rename SELF to STATIC_SELF, and
75 rename DYNSELF to SELF. Additionally, direct access to VTABLE functions should
76 be reviewed, and SELF should be used where possible to increase clarity and
77 maintainability (this is a good CAGE task.) Also, this should become a coding
78 standard for PMCs.
79
80 Allison: OK on the rename of DYNSELF to SELF, but we need a better name
81 than STATIC_SELF. Where is the non-dispatching version likely to be used
82 and why?
83
84 B<Att:> SELF is just a synonym for I<pmc> - the object - above is talking
85 about SELF.method() and alikes. See F<lib/Parrot/Pmc2c.pm>.
86
87
88 =item composition is almost non-existent (roles would be nice)
89
90 The current class composition uses interfaces, which seems inadequate. Roles
91 may make better composition units, but may not make supporting Perl 5 OO
92 easier. Leo, chromatic, Matt, and Jonathan traded ideas on the subject. It
93 seems more investigation and discussion is in order.
94
95 B<Recommendation>: Leo, chromatic, Matt, and Jonathan should exchange ideas
96 on the subject in a meeting within the next two weeks. Hopefully this
97 exchange of ideas will lead to clarity on a proposed solution to a class
98 composition model.
99
100 Allison: Definitely in favor of a composition model.
101
102 =item split VTABLE functions into related categories
103
104 Someone had mentioned the idea of splitting the PMC vtable functions into
105 groups of related functions that you could choose to implement or not
106 implement. All keyed vtable functions would go in one group, for example.
107
108 Leo pointed to a p2 thread on the topic:
109 L<http://groups.google.at/group/perl.perl6.internals/browse_thread/thread/9ea5d132cb6a328b/4b83e54a13116d7c?lnk=st&q=interface+vtable+Toetsch&rnum=2#4b83e54a13116d7c>
110
111 Others thought this idea sounded intriguing, and that it was worth pursuing.
112
113 B<Recommendation>: Elaboration on this idea is required in order to focus
114 thought on design considerations. No timeframe has been set.
115
116 Allison: Yes, needs a more complete proposal.
117
118 =back
119
120
121 =head2 List of problems and proposed solutions for objects:
122
123 =over 4
124
125 =item Class namespace is global
126
127 At present it is not possible for a HLL to define a classname that has
128 already been used by another HLL. (Example: PGE/Perl 6 cannot define a class
129 named 'Closure' because Parrot already has one.) Chip and chromatic
130 discussed this before the meeting, and Chip has a solution 'almost ready.'
131
132 Discussion moved into class/namespace relationships, and metaclasses as it
133 relates to method dispatch order, and the potential to incorporate roles
134 instead of metaclasses, which brought the tangent back to previous discussion
135 on class composition, before the discussion was tabled.)
136
137 B<Recommendation>: Chip, based on prior thought, as well as this discussion,
138 will detail his plan. We know it includes a registry of class names for each
139 HLL, but more will be revealed soon.
140
141 Allison: das ist gut.
142
143 =item PMC vtable entries don't work in subclasses (or subsubclasses)
144
145 Currently things are handled by deleg_pmc.pmc and default.pmc. Unfortunately,
146 it appears that calls to vtable entries in default.pmc take place before
147 delegation to a superclass. Patrick proposes that this be switched somehow;
148 e.g, inheritance should be preferred over default vtable entries.
149 See L<https://rt.perl.org/rt3//Ticket/Display.html?id=39329>.
150
151 B<Recommendation>: Inherit from default.pmc unless you have a parent. Always
152 check inheritance when dispatching, if necessary. Chip will look specifically
153 at Capture PMCs and attempt to provide a solution without architectural
154 changes, enabling Patrick's work to continue.
155
156 Allison: das ist gut. Also looks like a good point for potential
157 architectural changes in the updated objects PDD.
158
159 =item PMC methods aren't inherited by ParrotObject pmcs
160
161 A METHOD defined in a PMC won't work unless it's been specifically coded to
162 work in a PIR-based subclass. See L<http://xrl.us/s7ns>.
163
164 B<Recommendation>: All direct data access should go through accessors, except
165 for within the accessors themselves. This involves a code review of all core
166 and custom PMCs, which has been recommended above as well. This may require
167 further discussion, as Patrick did not seem confident that this statement was
168 sufficient to resolve the situation.
169
170 Patrick's after-meeting response: The unresolved issue I'm seeing is that
171 every PMC has to be aware of the possibility that SELF is a ParrotObject
172 instead of the PMC type. For example, src/pmc/capture.pmc currently
173 has its methods as
174
175 METHOD PMC* get_array() {
176 PMC* capt = SELF;
177 /* XXX: This workaround is for when we get here as
178 part of a subclass of Capture */
179 if (PObj_is_object_TEST(SELF))
180 capt = get_attrib_num(PMC_data(SELF), 0);
181 CAPTURE_array_CREATE(INTERP, capt);
182 return CAPTURE_array(capt);
183 }
184
185 It's the "if (PObj_is_object_TEST(SELF))" clause that bugs me --
186 does every PMC METHOD have to have something like this in order
187 for subclassing to work properly? That feels wrong. And I don't
188 see how the solution of "all direct data access goes through
189 accessors" applies to this particular situation... although I
190 could just be reading it wrong. --Pm
191
192 Allison: ParrotObjects and PMCs were intended to be completely
193 substitutable. Clearly they aren't yet, but the solution to the problem
194 is not to add more and more checks for whether a particular PMC is an
195 Object, but to give ParrotObjects and low-level PMCs the ability to be
196 subclassed through a single standard interface (even if each has
197 completely different code behind the interface making it work).
198
199 =item getattribute/setattribute efficiency
200
201 Dan used to often remark that sequences like the following were "very slow":
202
203 =begin PIR_FRAGMENT_INVALID
204
205 $P0 = getattribute obj, "foo"
206 $P1 = getattribute obj, "bar"
207 $P2 = getattribute obj, "baz"
208
209 =end PIR_FRAGMENT_INVALID
210
211 Instead, Dan suggested always using classoffset to obtain attributes:
212
213 =begin PIR_FRAGMENT_INVALID
214
215 $I0 = classoffset obj, "FooClass"
216 $P0 = getattribute obj, $I0 # which attr is this?
217 inc $I0
218 $P0 = getattribute obj, $I0 # and that?
219 inc $I0
220 $P0 = getattribute obj, $I0
221
222 =end PIR_FRAGMENT_INVALID
223
224 Unfortunately, this doesn't seem to be very practical in many respects. Can
225 we at least get a declaration from the designers about the appropriate style
226 to use for object attributes? I much prefer the former to the latter, and if
227 it's a question of efficiency we should make the former more efficient
228 somehow.
229
230 The latter takes 2 opcodes, which is per se suboptimal, The former is much
231 more readable, just one opcode and optimizable and never subject of any
232 caching effects of the offset (e.g. what happens, if the getattribute has
233 some nasty side-effects like adding new attributes?)
234
235 Oh well, and classoffset does of course not work for Hash-like or other
236 objects.
237
238 B<Recommendation>: Best practice is to use named attribute access.
239 Optimizations, if necessary, will be addressed closer to 1.0. Issues with
240 classoffset and hash-like objects will be addressed in the future as
241 necessary.
242
243 Allison: Agreed.
244
245 =back
246
247 =head1 AUTHOR
248
249 Jerry Gay L<mailto:jerry.gay@gmail.com>
250
251 =cut
Something went wrong with that request. Please try again.