I'm right now looking at getting a proper implementation of array/string
offsets done for the PHP compiler.

Here's the problem, in PHP you can access indices of both string's an
array's in the same way, meaning:

<?php
$foo = "hallo johnny";
echo $foo[1]; // "a"
?>

Is just as valid as:

<?php
$foo = array("a", "b", "c");
echo $foo[1]; // "b"
?>

To have this available easily using Perl's types, get_pmc_keyed() would
need to be implemented in the PerlString PMC.  Currently (for the sake
of nice looking mandelbrot demos), we just assume is a native string and
do the offset from that string (which parrot/imc does support.)

Should PerlString support a get_pmc_keyed() method (according to Perl
5/6 semantics), or is this a point where its about time to start implementing
our own PMCs?

-Sterling

Am 04.12.2003 um 15:17 schrieb Leopold Toetsch:

function dump0($a)
{
echo printf("%s\n",$a[0]);

would produce (in php):

h            // string offset
thies        // array index

how do you think we should generate "good" imc code for that?

re,
thies

  .sub _subscripted
  .param pmc p
  .param int idx
  does I0, p, "array"
  if I0, handle_array
  .include "pmctypes.pasm"
  typeof I0, p
  eq I0, .PerlString, handle_string
  # unhandled type
  exit 1
  .local pmc elem
handle_array:
  elem = p[idx];
  ...
handle_string:
  $S0 = p
  $S1 = $S0[idx] # or substr $S1, p, idx, 1
  elem = new .PerlString
  elem = $S1
  ...

absolutely untested.

But it seems, that subscripting of string PMCs yields another PMC in the
general case, so its really probably simpler to use your proposed
change. You can easily experiment with custom PMCs, if you use
dynclasses/*.

0x4C56

 Happy
         .~.
         /V\
        // \\
       /(   )\
        ^`~'^
                2004
   keeps comin'

I can see a number of solutions here, some of which involve compiler
hackery. The thing that first springs to mind is to have the PHP
compiler emit a check of some sort before use, and either do array
access or substring access. That's got a certain appeal to it, as it
means we don't have to do anything. :) (Well, not true--we have to
provide sufficient easily queryable metadata to tell if a variable is
more or less an array, or a string, but we ought to so that anyway)

If that's not a reasonable option, and I can see it not being so,
that makes things somewhat more interesting. Definitely calls for at
least one custom PMC for PHP, and potentially an automatic wrapping
function to throw a PHPStringWrapper (or whatever) around anything
stringlike that comes back from an 'external' function call. That
requires a bit more work on parrot's part, though, and, while I'd
like to do this at some point (for JVM and .NET native library
wrapping) I hadn't intended to do it yet, for lack of time and need.
--
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
d...@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk