*) I'd like to shoot for a Feb 14th release. Names wanted. (I'm
partial to the bleeding heart release, but not that partial)
*) Namespaces are going to use the:
find_global Px, [key; key; key], final_name_string
format. I may add in a dummy:
find_global Px, Pn[key], final_name
in the mean time just to make things work out. Pn will get ignored.
If you have the key and leave out the element, it returns a PMC that
represents that piece of the namespace. Yes, I know there are
objections, but it's a matter of taste and space savings. We'll cope.
*) Just constant keys for names right now. We'll work on dynamic keys
later, if we don't already have 'em in.
*) I like Tim's namespace idea (prepending the language) and we'll
put that in, though probably for the next release.
*) I'm just going to get the final damn object stuff finished. It's
80% there and I should just stop wincing every time I look at
objects...
*) It's time for doc patches! If folks have helpful suggestions or
experiences, post a patch to docs/practical_notes.pod in a =head2
section. Not as good as a full tutorial, but better than nothing.
Patch at the top so things slot in with a minimum of patch whining.
*) I'll try and patch up the docs, and I'll concentrate on the PDDs,
but any help on them is greatly appreciated. *Especially* IMCC docs.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
You can always find some reference to a bird in it somewhere
http://www.newadvent.org/cathen/15254a.htm
We could name it after the following painting/painter "Valentine Cameron
Prinsep" or one of his names. When people ask why we named it after a
saint we can tell them we didn't, we named it after a painter. He
painted the following picture.
http://www.artmagick.com/paintings/painting3593.aspx
she was having a bad hair day.
Or in a show of support for our fellow parrots:
We could call it the kakapo release or at least dedicate it to the
kakapo. Not sure if everyone would think a nearly extinct parrot is a
good metaphor ;-)
http://news.bbc.co.uk/1/hi/sci/tech/1849686.stm
Or we could go with the "lovebird" release. Lovebirds are some of the
smallest types of parrot. Please read more here.
http://www.parrotparrot.com/lovebirds/
> *) I'm just going to get the final damn object stuff finished. It's 80%
> there and I should just stop wincing every time I look at objects...
This would be lovely.
> *) It's time for doc patches! If folks have helpful suggestions or
> experiences, post a patch to docs/practical_notes.pod in a =head2
> section. Not as good as a full tutorial, but better than nothing. Patch
> at the top so things slot in with a minimum of patch whining.
>
> *) I'll try and patch up the docs, and I'll concentrate on the PDDs, but
> any help on them is greatly appreciated. *Especially* IMCC docs.
Do we need an NCI section in the IMCC.faq. If the vote is yes I do not
mind knocking something up.
Harry
I'd vote yes!
Thanks.
Tim.
> *) I'd like to shoot for a Feb 14th release. Names wanted. (I'm
> partial to the bleeding heart release, but not that partial)
I had planned towards Feb 29th. A nice dated too this year.
> *) Namespaces are going to use the:
> find_global Px, [key; key; key], final_name_string
> format. I may add in a dummy:
> find_global Px, Pn[key], final_name
> in the mean time just to make things work out. Pn will get ignored.
> If you have the key and leave out the element, it returns a PMC that
> represents that piece of the namespace. Yes, I know there are
> objections, but it's a matter of taste and space savings. We'll cope.
I'd add some syntax additions and some notes:
- Pn above is a NameSpace PMC, derived from Hash
- an interpreter has a current namespace
- located in the context, so that its restored after sub calls
getinterp P2
find_global Pn, P2["."] # get current NS
find_global Pz, P2[".."] # get parent NS
set Pz, Pn[".."] # same
find_global Py, P2["/"] # get root of namespaces
find_global Px, Pn["Foo"; "Bar"] # NS of Module Foo::Bar
find_global Pv, Pn["Foo"; "Bar"], "baz" # $Foo::Bar::baz var
find_global Pv, Pn["Foo"; "Bar"; "baz" ] # same
set P2["."], Px # switch current NS to Foo::Bar
find_global Pv, Pn["/"; "java"; "some"; "glob" ] # /java.some.glob
> *) Just constant keys for names right now. We'll work on dynamic keys
> later, if we don't already have 'em in.
Dynamic keys are (still) working ;)
> *) I like Tim's namespace idea (prepending the language) and we'll
> put that in, though probably for the next release.
That's not really difficult, if the namespace PMC handles above
directory-like traversal keys.
leo
¡Me gusta mucho!
This system allows neato things like anonymous namespaces, too.
I was thinking of something similar for classes. An object holds a
reference to a class PMC which is used to fetch its methods. This
allows different metaclasses (which are, again, required for Perl 6[1]).
Maybe said class PMC is, by default, just an anonymous namespace PMC.
Luke
Works for me.
> > *) Namespaces are going to use the:
>
> > find_global Px, [key; key; key], final_name_string
>
> > format. I may add in a dummy:
>
> > find_global Px, Pn[key], final_name
>
>I'd add some syntax additions and some notes:
>
>- Pn above is a NameSpace PMC, derived from Hash
The problem there is that there's just no point, really. Might as
well not bother with find_global and just use normal hash access.
Arguably that's what we ought to do, I suppose, but things are
sufficiently different that I'd as soon not. (That and it's an
otherwise useless parameter in most cases, which fluffs up the
instruction stream)
> > *) Just constant keys for names right now. We'll work on dynamic keys
>> later, if we don't already have 'em in.
>
>Dynamic keys are (still) working ;)
I thought so, but I wasn't sure.
> > *) I like Tim's namespace idea (prepending the language) and we'll
>> put that in, though probably for the next release.
>
>That's not really difficult, if the namespace PMC handles above
>directory-like traversal keys.
Oh, it's going to have to. The namespace stuff's going to have to be
annoyingly complex, unfortunately.
DS> At 4:28 PM +0100 2/4/04, Leopold Toetsch wrote:
>> Dan Sugalski <d...@sidhe.org> wrote:
>>> Okay, here's a quick scoop and status.
>>
>>> *) I'd like to shoot for a Feb 14th release. Names wanted. (I'm
>>> partial to the bleeding heart release, but not that partial)
>>
>> I had planned towards Feb 29th. A nice dated too this year.
DS> Works for me.
then how about calling it the bleaping <insert avian> release? :)
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
>>>>>> "DS" == Dan Sugalski <d...@sidhe.org> writes:
>
> DS> At 4:28 PM +0100 2/4/04, Leopold Toetsch wrote:
> >> Dan Sugalski <d...@sidhe.org> wrote:
> >>> Okay, here's a quick scoop and status.
> >>
> >>> *) I'd like to shoot for a Feb 14th release. Names wanted. (I'm
> >>> partial to the bleeding heart release, but not that partial)
> >>
> >> I had planned towards Feb 29th. A nice dated too this year.
>
> DS> Works for me.
>
> then how about calling it the bleaping <insert avian> release? :)
The Leaping Kakapo release?