On 1/19/06, chromatic <[EMAIL PROTECTED]> wrote: > On Thursday 19 January 2006 19:50, Rob Kinyon wrote: > > > Nothing. Just like it's not a problem if Perl6 uses one of the > > Ruby-specific PMCs for storage. In fact, the alternate $repr idea is > > specifically to allow for the use of foreign datatypes as storage. > > Luke's excellent example is to use a C-struct as your storage. > > ... but ... > > > Storage of what? What are you trying to do that you need to use an > > object to store your attributes? Why aren't you just using the method > > -that- object is using? > > I can't reconcile these two paragraphs.
The second paragraph was referring solely to where you're dealing with Parrot datatypes only. If you have to go outside of Parrot (to a C lib, for instance), then you do need to know about the storage specifics. > > No. My objection to bless() is BUILD() and CREATE(). There's already a > > mechanism in the P6 OO system for specifying the internal > > representation of the instance. > > This is Perl. The "there should be one obvious way to do it" ship, canoe, > raft, and water wings have sailed, paddled, floated, and inflated. And there is. You can create your own meta-object protocol on top of p6opaque or any other representation you want. This is *Perl6* - you can rewrite the whole damn grammar if you want to. You can use another VM if you want to. (PIL^N runs on Javascript!) I think this entire issue is rising out of the fact that very very few people in this discussion are familiar with the design of the MOP. Stevan and a few others are the primary movers and I'm lucky enough to have been Stevan's sounding board for a few pieces. Once you grok the MOP, it's really hard to imagine wanting to use bless(). It's literally like trying to explain to a BASIC programmer why recursion is good or trying to explain to a C programmer why automatic memory management is handy. The frames of reference are so different that the meaning being trasmitted is not the meaning being received. Rob
