On Sat, Feb 03, 2001 at 05:02:27PM +0100, Edwin Steiner wrote:
> - This scheme could become a mess, if abused.
That's exactly what happened to Perl 5, which your scheme looks strikingly
similar to.
--
I detest people who get in their cars before turning off the
alarm, fiddle around a bit, and
At 05:02 PM 2/3/2001 +0100, Edwin Steiner wrote:
>Might this be madness? (BRAINSTORMS AHEAD!):
Generally, yes. :)
The vtable stuff won't be exposed outside the core. This means embedding
programs and extensions will *not* be using it. Generally speaking, it'll
be opcode functions only that'll
At 12:21 PM 2/3/2001 +0100, Edwin Steiner wrote:
>Matthew Cline wrote:
> >
> > We might want to have a member/method by which we can tell what type of
> > variable we're dealing with, so that a function can be passed an arbitrary
> > XV, and treat it differently if it's an SV, AV, and so on.
> >
>
At 10:06 AM 1/31/2001 -0200, Branden wrote:
>Matthew Cline wrote:
> > Should there be method to tell an SV to change the internal representation
>of
> > the data? For example, if an SV was created as a string, but is being
>turned
> > into a float over and over again for use in equations, it woul
Might this be madness? (BRAINSTORMS AHEAD!):
The API of the Perl data types could be specified
in the following way:
*) a class hierarchy (hopefully not a deep one).
eg.
AnyV (XV?)
|
-
| | | |
SV
Matthew Cline wrote:
>
> We might want to have a member/method by which we can tell what type of
> variable we're dealing with, so that a function can be passed an arbitrary
> XV, and treat it differently if it's an SV, AV, and so on.
>
> For SVs, we might want to have a method to determine what
