Re: RFC Magic::Attach

After the earlier brief discussion, I thought about the similarity between this feature and "properties" in Perl 6. I think it would be useful to design the front-end in such a way that it can be re-coded to use properties (mimicing the property syntax of Perl 6 directly is probably not practical without a source filter, and it may change before it sees first light anyway so it doesn't seem worth the effort, unless you want to specifically explore the Perl 6 feature in applied use before it's too late to redesign it).

I don't think the example at the end of your post is a good example. Why must your tuple be crammed into a simple scalar? That looks like the job for an iterator class based on a blessed array of two items, and possibly an overloaded stringize or numify operator.

—John

Comment on Re: RFC Magic::Attach

Replies are listed 'Best First'.
Re: Re: RFC Magic::Attach by shotgunefx (Parson) on Jan 21, 2003 at 08:54 UTC
I'm not up to speed on Perl 6. Between life and work I've been really squeezed. That's why I cursed you for asking that question :), if time permits I'll look into it. I do want to add callbacks though. One of my side projects is a perl-like language written in Perl. It's the basis for Yet Another Template Language. (Yes, I know it's been done to death) I want to avoid direct evaluation entirely. One thing that occured to me is that I could add a hook to any evaluated symbol or variable and use it to invalidate cached expressions when they are updated. (Most likely > half of the expressions won't change under iteration.) I agree about the example, that's why I labeled them trivial. After the time I spent on this I was too fried and pressed for time to come up with something compelling. Why must your tuple be crammed into a simple scalar? I'm not sure what you mean by this. Do you mean that the positions are stored in an array ref? While I use iterators, I don't like the syntax. Most if not all of my motivation of getting into the guts of Perl is to try and bend it to my will :) I've actually spent a lot of time trying to fathom the guts of Perl and it all started because of an iterator op I wanted to write and couldn't (The way it should work anyway) findone { coderef } @array. Though the examples are not great, it is common to want to attach some data to another piece of data. We do this all the time with lexical hashes and stringified refs, etc. After your question, it just seemed like a cool thing to do that might be practical. I personally dislike ties, or anything else that makes me change they way I would write something or requires prep work on my end. I also don't want subs messing with their callers. So it just seemed like a good way to accomplish it while improving my understanding of internals. Any thoughts on requiring a "nameid"? The more I think about it, the more I think it should be required. I didn't want to call it a "packagename" as that was confusing. nameid is pretty bad too though. Perhaps "slotname"? -Lee "To be civilized is to deny one's nature."	[reply]
Re: Re: Re: RFC Magic::Attach by John M. Dlugosz (Monsignor) on Jan 21, 2003 at 21:29 UTC
Yes, the property name should be required. In exegesis 2, it shows that the new keyword `is` will assign a named property to a value: `$val is Found(0)` is sugary syntax for something like `attach (\&val, Found => 0)`. For looking it up, it shows treating the plain scalar value like a hash. There's got to be a longer way, or it would have problems when the value is a hash. The Apocalypse probably shows more detail, but that's already changed so don't get too, er, attached to it. I think last I heard run-time properties used the `but` keyword. But, Apocalypse 2 (end of the properties section) gives "a list of property ideas" that you might try using with your stuff. —John	[reply] [d/l] [select]


good chemistry is complicated, and a little bit messy -LW
	PerlMonks