PMC Methods, Inheritance, and User-visible Classes

[Matt Diephouse]

I'm going to start working on an AbstractPMCArray PMC class that can
provide some default array vtable functions for other PMCs to inherit.
This will give array classes some functionality for free.
AbstractPMCArray will implement splice, for example, which can be
implemented using an array's external interface.

I would like to add some sort methods as well: quicksort(),
mergesort(), etc. But as methods, there is potential for these to end
up in a user-visible space.

Say for example, that I add a mergesort method to AbstractPMCArray.
Ruby's array class wouldn't be able to use AbstractPMCArray as a base
class because there is no mergesort method on an Array in Ruby.

Tcl has it easy because there's no OO support (everything is a string,
not an object). So we're mainly interested in adding methods that make
our lives easier and don't have to worry about user-visible methods.
And I can imagine that other compiler writers would want to use
methods like these without having to expose them.

One possible route is two implement two classes: an AbstractPMCArray
class that only provides vtable functions and an
AbstractPMCArrayWithMethods class that inherits from AbstractPMCArray
and adds methods into the mix.

But then there's also the question of how FixedPMCArray and
ResizablePMCArray should behave. Should they have methods on them
(which will be user-visible)? They do right now, but that's not
correct if compiler writers are expected to use these as the basis for
their array classes. Would these each need to be split into 2 classes
as well? If so, we'd want to make multiple inheritance really work
with PMCs.

Any thoughts?

--
Matt Diephouse
http://matt.diephouse.com

[Joshua Juran]

On Aug 28, 2006, at 12:18 PM, Matt Diephouse wrote:

> I would like to add some sort methods as well: quicksort(),
> mergesort(), etc. But as methods, there is potential for these to end
> up in a user-visible space.
>
> Say for example, that I add a mergesort method to AbstractPMCArray.
> Ruby's array class wouldn't be able to use AbstractPMCArray as a base
> class because there is no mergesort method on an Array in Ruby.
>

> Any thoughts?

How about requiring array classes to implement swap(), and then
implementing sort algorithms in terms of that, as in C++?

Josh

[Matt Diephouse]

Adding swap() would remove a level or two of indireciton, but this
ignores the underlying problem of methods on PMCs leaking into
user-visible spaces.

[Watson Ladd]

Let's do what the STL does and have hundreds of parent classes that have
only limited functionality in order to permit people to force themselves
to recreate it. Seriously, what's so bad about adding functionality into
a language?

--
They who would give up an essential liberty for temporary security,
deserve neither liberty or security
--Benjamin Franklin

[Chromatic]

On Wednesday 30 August 2006 04:12, Watson Ladd wrote:

> Seriously, what's so bad about adding functionality into
> a language?

I once saw an overfilled waterbed that was almost as tall as I am. I would
have called it PHP, but it didn't explode and throw cold water all over the
house.

-- c

[Luke Palmer]

Tons of people use PHP. Why? Because it gets the job done, and it
has tons of functionality. The problem with PHP is not that it has
too much functionality, but that it is organized extremely poorly.

Luke

[Mark J. Reed]

On 8/30/06, Luke Palmer <lrpa...@gmail.com> wrote:
>
> The problem with PHP is not that it has
>
too much functionality, but that it is organized extremely poorly.

Amen. PHP is the poster child for namespace pollution. And PHP5 actually
has the tools to stop the madness; it's just a question of backward
compatibility.

I also really hate the HTML-multivalued-input-names-have-[] hack.

And I'm not fond of the "arrays are just hashes with numeric keys"
philosophy (which it shares with JavaScript).

But other than that, I love PHP. ;-)

--
Mark J. Reed <mark...@mail.com>

[Peter Baylies]

On 8/31/06, Mark J. Reed <mark...@mail.com> wrote:
>
> On 8/30/06, Luke Palmer <lrpa...@gmail.com> wrote:
> >
> > The problem with PHP is not that it has
> >
> too much functionality, but that it is organized extremely poorly.
>
>
> Amen. PHP is the poster child for namespace pollution. And PHP5 actually
> has the tools to stop the madness; it's just a question of backward
> compatibility.
>
> I also really hate the HTML-multivalued-input-names-have-[] hack.

My personal gripe is the bizarre way PHP handles scope--what with its
hardcoded superglobals, globals, locals, so far so good I suppose, and
then... shadowing all the globals when inside a function? Too weird.

And I'm not fond of the "arrays are just hashes with numeric keys"
> philosophy (which it shares with JavaScript).

That I don't mind so much--from a utility point of view, PHP's unified
arrays/hashes are great, almost like a swiss army knife of data structures.

[Chromatic]

On Wednesday 30 August 2006 19:14, Luke Palmer wrote:

> The problem with PHP is not that it has
> too much functionality, but that it is organized extremely poorly.

That's really my point. I'm all for adding necessary features to Parrot where
they're appropriate, but not in such a way that they get in my way when I
want nothing to do with them.

-- c