Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 20, 2001 at 03:16:12PM +0100, Chris boris Ross wrote:
> > I also think this problem should be resolved especially as I think a common
> > Virtual machine would be a _very_ good thing.
>
> I *would* dearly, dearly love to see a way to resolve this, but I can't think
> of a good one that keeps everyone happy.
I suspect there's a middle ground that everyone can compromise on.
In any s/w project, there are few basic types (and concepts) that
everyone should have been expected to understand before they can
realistically start hacking. For these things, it is okay to give short
snappy names. For example, Perl 5 is basically a big engine for the
manipulation of scalar values. Regardless of whether we call them SV or
Scalar_variable_t or whatever, we wouldn't want to let people loose
until they understood their basic properties. So we might as well call
them SV, since every 2nd variable in the Perl src is going to be an
SV*.
On the other hand, there are lots of functions you can apply to SVs.
It is unreasonable to expect newcomers to memorise the entire list just
to be able to understand a bit of code. so SvPV(sv) is bad;
SV_str_ptr(sv) is probably better.
Ditto for parrot. The only debate is which things count as basic.
(Of course, there must be a document somewhere which explains the
naming scheme. In Perl 5 there's perlguts.pod; for parrot there are some
PDDs (parrot/perl design document) which are supposed to do this.)
Dave M.
