| | 1 | {{{ |
| | 2 | allison> The most important things are a) to merge C PMCs with PIR PMCs, b) to keep two |
| | 3 | sets of object behavior (roughly corresponding to our current "vtables" and |
| | 4 | "methods") one being publicly accessible to users, the other providing base functionality |
| | 5 | allison> c) to provide attributes storage and retrieval, d) to provide invocation for both |
| | 6 | public and hidden functionality |
| | 7 | |
| | 8 | <snip> |
| | 9 | |
| | 10 | cotto> allison, what are the necessary and sufficient criteria need to be met for Parrot's new |
| | 11 | object model? The points you mentioned earlier seem necessary but not sufficient. |
| | 12 | allison> cotto: yes, that was describing the M0 level |
| | 13 | NotFound> cotto: it should work |
| | 14 | cotto> So anything that meets those criteria is a good possibility? |
| | 15 | allison> cotto: sufficient is "able to provide the base features necessary to implement |
| | 16 | Rakudo/Python/PHP/etc" object model |
| | 17 | allison> cotto: plus "able to provide the standard features those different models will use to |
| | 18 | talk to each other" |
| | 19 | cotto> I suppose "efficiently" should be in there too. |
| | 20 | allison> yah, efficiency is huge |
| | 21 | }}} |
