perl 5.0 alpha 8
[p5sagit/p5-mst-13.2.git] / internals
index 471ad95..fbf686e 100644 (file)
--- a/internals
+++ b/internals
@@ -34,6 +34,8 @@ article, I can and probably should relax that.  That code is some of
 the oldest Perl 5 code, and I didn't see some things then that I do
 now.
 
+[I did relax that.]
+
 Ok, let me explain some things about how values are stored.  Consider
 this a little design document.
 
@@ -55,6 +57,8 @@ struct sv {
     U8         sv_private;     /* extra value, depending on type */
 };
 
+[The last 4 bytes have been combined into a single U32.]
+
 This is typedefed to SV.  There are other structurally equivalent
 types, AV, HV and CV, that are there merely to help gdb know what kind
 of pointer sv_any is, and provide a little bit of C type-checking.
@@ -70,6 +74,7 @@ Additionally I often use names containing
        IV      integer value
        NV      numeric value (double)
        PV      pointer value
+       RV      reference value
        LV      lvalue, such as a substr() or vec() being assigned to
        BM      a string containing a Boyer-Moore compiled pattern
        FM      a format line program
@@ -95,6 +100,9 @@ typedef enum {
        SVt_PVFM,
 } svtype;
 
+[There is no longer a REF type.  There's an RV type that holds a minimal ref
+value but other types can also hold an RV.  This was to allow magical refs.]
+
 These are arranged ROUGHLY in order of increasing complexity, though
 there are some discontinuities.  Many of them indicate that sv_any
 points to a struct of a similar name with an X on the front.  They can
@@ -105,7 +113,8 @@ be classified like this:
 
     SVt_REF
        The sv_any points to another SV.  (This is what we're talking
-       about changing to work more like IV and NV below.)
+       about changing to work more like IV and NV below.)  [And that's what
+       I did.]
 
     SVt_IV
     SVt_NV
@@ -120,6 +129,7 @@ be classified like this:
        memory.  This does waste a few allocated integers(doubles) at
        the beginning, but it's probably an overall win.
 
+    [SVt_RV probably belongs here.]
     SVt_PV
     SVt_PVIV
     SVt_PVNV
@@ -127,6 +137,15 @@ be classified like this:
        These are pretty ordinary, and each is "derived" from the
        previous in the sense that it just adds more data to the
        previous structure.
+[ Need to add this:
+       struct xrv {
+           SV *        xrv_rv;         /* pointer to another SV */
+       };
+
+           A reference value.  In the following structs its space is reserved
+           as a char* xpv_pv, but if SvROK() is true, xpv_pv is pointing to
+           another SV, not a string.
+]
 
        struct xpv {
            char *      xpv_pv;         /* pointer to malloced string */
@@ -187,23 +206,30 @@ be classified like this:
        These are specialized forms that are never directly visible to
        the Perl script.  They are independent of each other, and may
        not be promoted to any other type.
+       [Actually, PVBM doesn't belong here, but in the previous section.
+       saying index($foo,$bar) will in fact turn $bar into a PVBM so that
+       it can do Boyer-Moore searching.]
 
 There are several additional data values in the SV structure.  The sv_refcnt
 gives the number of references to this SV.  Some of these references may be
 actual Perl language references, but many other are just internal pointers,
 from a symbol table, or from the syntax tree, for example.  When sv_refcnt
-goes to zero, the value can be safely deallocated.
+goes to zero, the value can be safely deallocated.  Must be, in fact.
 
 The sv_storage byte is not very well thought out, but tends to indicate
 something about where the scalar lives.  It's used in allocating
 lexical storage, and at runtime contains an 'O' if the value has been
 blessed as an object.  There may be some conflicts lurking in here, and
-I may eventually claim some of the bits for other purposes.
+I may eventually claim some of the bits for other purposes.  [I did,
+with a vengeance.]
 
 The sv_flags are currently as follows.  Most of these are set and cleared
 by macros to guarantee their consistency, and you should always use the
 proper macro rather than accessing them directly.
 
+[Most of these numbers have changed, and there are some new flags.
+And they're all stuffed into a single U32.]
+
 #define SVf_IOK                1               /* has valid integer value */
 #define SVf_NOK                2               /* has valid numeric value */
 #define SVf_POK                4               /* has valid pointer value */