Mailing List Archive: Perl: porters

Objects without stashes?

1 2

View All

Index | Next | Previous | View Threaded

fawaka at gmail

May 25, 2012, 7:47 AM

Post #1 of 35 (278 views)
Permalink

Objects without stashes?

I hate the way classes/objects work. In particular, I think stashes of
globs of other stuff is paradigm that fails, and I don't think I stand
alone in that. We all know how much effort it is to work with them,
even when abstractions are available that make them less inconvenient.
It makes me wonder why we're sticking to it so badly? Perl has always
had a very minimalistic definition definition of what an object is. To
quote perltoot:

> An object is different from any other data type in Perl in one and only one way: you may dereference it using not merely string or numeric subscripts as with simple arrays and hashes, but with named subroutine calls. In a word, with methods.

There is nothing, absolutely nothing, about this that requires stashes
(or for that matter, there's nothing that requires packages/classes
either). What if we simply added a vtable to all objects when
blessing? At its minimal, this vtable would only need to support two
methods: fetchmethod and ref, though more may be prudent (meta would
be an obvious one, clone and destroy may be useful too). I think this
would allow us to add new paradigms in a sensible and extensible way,
without breaking too many other things.

Leon

pagaltzis at gmx

May 25, 2012, 8:41 AM

Post #2 of 35 (277 views)
Permalink

Re: Objects without stashes? [In reply to]

* Leon Timmermans <fawaka [at] gmail> [2012-05-25 16:55]:
> I think stashes of globs of other stuff is paradigm that fails, and
> I don't think I stand alone in that. We all know how much effort it is
> to work with them, even when abstractions are available that make them
> less inconvenient. It makes me wonder why we're sticking to it so
> badly?

At the far end of that question lies, of course, Perl 6. :-)

> What if we simply added a vtable to all objects when blessing? At its
> minimal, this vtable would only need to support two methods:
> fetchmethod and ref, though more may be prudent (meta would be an
> obvious one, clone and destroy may be useful too).

How do things get into the vtable? What syntax is provided, how does it
interoperate or interact with the traditional approach of writing subs
in a package? Do you break every single line of meta-programming code in
Perl ever written? Do you half break it? Or do you try somehow to make
this change transparent? How much does that limit you?

Or am I misunderstanding – is all you want a pure implementation detail?
(I.e. what continues to look like a package to Perl code is implemented
using vtables underneath so that it’s easier to code against.)

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

ikegami at adaelis

May 25, 2012, 10:40 AM

Post #3 of 35 (274 views)
Permalink

Re: Objects without stashes? [In reply to]

On Fri, May 25, 2012 at 10:47 AM, Leon Timmermans <fawaka [at] gmail> wrote:

> > An object is different from any other data type in Perl in one and only
> one way: you may dereference it using not merely string or numeric
> subscripts as with simple arrays and hashes, but with named subroutine
> calls. In a word, with methods.
>
> There is nothing, absolutely nothing, about this that requires stashes
> (or for that matter, there's nothing that requires packages/classes
> either). What if we simply added a vtable to all objects when
> blessing? At its minimal, this vtable would only need to support two
> methods: fetchmethod and ref, though more may be prudent (meta would
> be an obvious one, clone and destroy may be useful too). I think this
> would allow us to add new paradigms in a sensible and extensible way,
> without breaking too many other things.
>

Interesting! What if it was possible to overload method resolution by
placing magic on the object? The object wouldn't even need to be blessed,
so gone is the requirement for a stash. Seems this avoids all compatibility
problems while providing a completely flexible system. It would allow one
to create (a module that creates) anon classes, or even class-less objects
like in JavaScript.

- Eric

ikegami at adaelis

May 25, 2012, 10:42 AM

Post #4 of 35 (273 views)
Permalink

Re: Objects without stashes? [In reply to]

On Fri, May 25, 2012 at 1:40 PM, Eric Brine <ikegami [at] adaelis> wrote:

> Interesting! What if it was possible to overload method resolution by
> placing magic on the object? The object wouldn't even need to be blessed,
> so gone is the requirement for a stash. Seems this avoids all compatibility
> problems while providing a completely flexible system. It would allow one
> to create (a module that creates) anon classes, or even class-less objects
> like in JavaScript.
>

I think all of that be done on cpan by hooking into the method call
checker, so this could actually be prototyped outside of core.

fawaka at gmail

May 25, 2012, 11:17 AM

Post #5 of 35 (277 views)
Permalink

Re: Objects without stashes? [In reply to]

On Fri, May 25, 2012 at 5:41 PM, Aristotle Pagaltzis <pagaltzis [at] gmx> wrote:
> How do things get into the vtable? What syntax is provided, how does it
> interoperate or interact with the traditional approach of writing subs
> in a package?

I don't intend any current code to have different semantics, the
default vtable will do the whole stashes dance the way we're used to.
Other object implementations may have other ideas. For example a mop
could use something simpler than the stashes-with-globs. Or maybe
someone writes a nice prototype based OO system. Possibilities are
endless.

> Do you break every single line of meta-programming code in
> Perl ever written? Do you half break it? Or do you try somehow to make
> this change transparent? How much does that limit you?

Anything that uses the old behavior will keep working exactly the
same. Though trying to use stash based introspection on non stash
based objects wouldn't work obviously. I'm sure we can deal with that
somehow, but that seems bike-shedding for now.

> Or am I misunderstanding – is all you want a pure implementation detail?
> (I.e. what continues to look like a package to Perl code is implemented
> using vtables underneath so that it’s easier to code against.)

Nothing should change for anything that exists now.

Leon

rurban at x-ray

May 25, 2012, 11:47 AM

Post #6 of 35 (273 views)
Permalink

Re: Objects without stashes? [In reply to]

On Fri, May 25, 2012 at 1:17 PM, Leon Timmermans <fawaka [at] gmail> wrote:
> On Fri, May 25, 2012 at 5:41 PM, Aristotle Pagaltzis <pagaltzis [at] gmx> wrote:
>> How do things get into the vtable? What syntax is provided, how does it
>> interoperate or interact with the traditional approach of writing subs
>> in a package?
>
> I don't intend any current code to have different semantics, the
> default vtable will do the whole stashes dance the way we're used to.
> Other object implementations may have other ideas. For example a mop
> could use something simpler than the stashes-with-globs. Or maybe
> someone writes a nice prototype based OO system. Possibilities are
> endless.

Simplier? A MOP will always be more complicated and slower.
Our approach is always more general than the tighter OO systems in
other languages you are thinking of.

I see no big improvement, unless your method and fields vtable can be
pre-optimized to
indexed access instead of hash lookup at compile-time, for which we
lack syntax:
read-only packages, eg.
We have some optimization for field access since a decade. It was not
the break-through
improvement as rarely somebody uses it.

Please read Stevan's MOP notes on github.
https://github.com/stevan/p5-mop/blob/master/lib/mop/proposal/intro.pod

Seperating subs from object methods and fields might be interesting
as they can be pre-optimized, but a conventional vtable makes no sense
with our dynamic perl.

It would have made sense if we had revamped our types and
used vtables for these, (int, string, classes...) which could be
extended to a new MOP.
But on the perl level it makes not much sense with our VM.
Stashes are the best implementation I foresee.

>> Do you break every single line of meta-programming code in
>> Perl ever written? Do you half break it? Or do you try somehow to make
>> this change transparent? How much does that limit you?
>
> Anything that uses the old behavior will keep working exactly the
> same. Though trying to use stash based introspection on non stash
> based objects wouldn't work obviously. I'm sure we can deal with that
> somehow, but that seems bike-shedding for now.
--
Reini Urban
http://cpanel.net/ � http://www.perl-compiler.org/

rurban at x-ray

May 25, 2012, 11:51 AM

Post #7 of 35 (277 views)
Permalink

Re: Objects without stashes? [In reply to]

On Fri, May 25, 2012 at 1:47 PM, Reini Urban <rurban [at] x-ray> wrote:
> Please read Stevan's MOP notes on github.
> �https://github.com/stevan/p5-mop/blob/master/lib/mop/proposal/intro.pod

Esp. those two arguments against our stash based methods:
https://github.com/stevan/p5-mop/blob/master/lib/mop/proposal/internals/rants.pod

fawaka at gmail

May 25, 2012, 12:21 PM

Post #8 of 35 (277 views)
Permalink

Re: Objects without stashes? [In reply to]

On Fri, May 25, 2012 at 7:42 PM, Eric Brine <ikegami [at] adaelis> wrote:
> I think all of that be done on cpan by hooking into the method call checker,
> so this could actually be prototyped outside of core.

I don't think that has the right scoping. It would break in any
calling code that was compiled before the call checker was loaded. I
don't think it would allow for a serious implementation, though it
could make an interesting experiment.

Leon

perl.p5p at rjbs

May 25, 2012, 1:20 PM

Post #9 of 35 (273 views)
Permalink

Re: Objects without stashes? [In reply to]

* Eric Brine <ikegami [at] adaelis> [2012-05-25T13:40:38]
>
> Interesting! What if it was possible to overload method resolution by
> placing magic on the object? The object wouldn't even need to be blessed,
> so gone is the requirement for a stash. Seems this avoids all compatibility
> problems while providing a completely flexible system. It would allow one
> to create (a module that creates) anon classes, or even class-less objects
> like in JavaScript.

I proposed this in 2008:

http://markmail.org/message/3wwf7pra3whfks5n

Later, I produced a shambling implementation:

http://rjbs.manxome.org/rubric/entry/1739

http://advent.rjbs.manxome.org/2010/2010-12-24.html

It was very exciting, to me, to have things half-working, but the second 90%
was problematic. Florian's anonymous stashes were useful, but wouldn't survive
threaded builds, and the idea of building it all with magic on the stashes was
grody, to put it lightly.

To what extent does this sort of thing prefigure Stevan Little work on p5-mop?
While I'd love to have this feature, we wouldn't want the two to play against
one another.

--
rjbs

Attachments:

signature.asc (0.48 KB)

stevan.little at iinteractive

May 25, 2012, 2:36 PM

Post #10 of 35 (265 views)
Permalink

Re: Objects without stashes? [In reply to]

On May 25, 2012, at 10:47 AM, Leon Timmermans wrote:

> I hate the way classes/objects work. In particular, I think stashes of
> globs of other stuff is paradigm that fails, and I don't think I stand
> alone in that. We all know how much effort it is to work with them,
> even when abstractions are available that make them less inconvenient.
> It makes me wonder why we're sticking to it so badly? Perl has always
> had a very minimalistic definition definition of what an object is. To
> quote perltoot:
>
>> An object is different from any other data type in Perl in one and only one way: you may dereference it using not merely string or numeric subscripts as with simple arrays and hashes, but with named subroutine calls. In a word, with methods.
>
> There is nothing, absolutely nothing, about this that requires stashes
> (or for that matter, there's nothing that requires packages/classes
> either). What if we simply added a vtable to all objects when
> blessing? At its minimal, this vtable would only need to support two
> methods: fetchmethod and ref, though more may be prudent (meta would
> be an obvious one, clone and destroy may be useful too). I think this
> would allow us to add new paradigms in a sensible and extensible way,
> without breaking too many other things.
>

So, I agree with everything you are saying, and actually this is very similar to the core instance type we are working on in the p5-mop project. If you distill down OO to its very essence you basically need two things. First is an instance type, something that can store instance scoped data, and second is a way to dispatch code (notice I didn't say method here) dynamically to an invocant (which itself is an instance type). Once you have these two things, you can build an entire object system on top of it (class based, prototype based, whatever).

To discuss your specific proposal, to start with, I like it, it removes a chunk of semi-ugly magic we are doing in the p5-mop to get dispatchable objects. I have a few concerns, all of which I think can be worked around.

I think you might run into a circularity issue with fetchmethod and ref being actual methods (how can fetchmethod fetch fetchmethod?), but this is the compromise of bootstrapping, so perhaps you make this a function call instead, after which you can make a method called fetchmethod that could call it (with some protections for infinite looping of course). We actually do something like this in the p5-mop internals for executing methods [1] but it does get a little messy (and mind-numbing at times).

Inheritance can be tricky, so either the vtable structure itself needs to know about it (which is the case with most vtable implementations) or the vtable needs to get locked at some point so that it can flatten out the inheritance hierarchy. Again, we are doing something similar in the p5mop in how we are using Package::Anon [2].

I don't think a meta method is needed, that can be lashed on via some kind of object system bootstrap, clone probably could be implemented in user-space as well, but destroy makes me wonder. It requires a knowledge about the outside scope that user-space code won't have. My only word of caution here is that destroy methods might be a slippery slope of infinitely recursive recursion, so might be best to handle it similar to how fetchmethod and ref would be handled.

Okay, thats my two cents. Thanks for including me in the CC.

- Stevan

[1] The core code is here (https://github.com/stevan/p5-mop/blob/master/lib/mop/internal/instance.pm) and I would expect if this were ever to make it into the core would be part of something like a MV (Method) structure and just be how the method is executed. Then in order to make Method::execute work in the MOP and to actually make it override able (because what good is a MOP if you can't totally muck with guts in that way) we do some manual "surgery" here (https://github.com/stevan/p5-mop/blob/master/lib/mop/bootstrap.pm#L111). The result is you get the ability to do insanity like this (https://github.com/stevan/p5-mop/blob/master/t/030-extensions/003-wrapping-methods.t) if you want too.

[2] we create/fetch a stash for each class from here (https://github.com/stevan/p5-mop/blob/master/lib/mop/internal.pm#L81) and then in the FINALIZE event of the Class object we populate the stash with a completely flattened method table (https://github.com/stevan/p5-mop/blob/master/lib/mop/bootstrap.pm#L405).

fawaka at gmail

Jul 6, 2012, 9:34 AM

Post #11 of 35 (242 views)
Permalink

Re: Objects without stashes? [In reply to]

On Fri, May 25, 2012 at 8:47 PM, Reini Urban <rurban [at] x-ray> wrote:
> Simplier? A MOP will always be more complicated and slower.
> Our approach is always more general than the tighter OO systems in
> other languages you are thinking of.

I don't think a MOP has to be slower, in fact I can imagine it being
faster than what we're using now. Currently we have to deal with lot
of the overhead due to the mismatch between the kind of semantics
people want (powerful stuff like a mop) and the building blocks we
have available to build that (stashes/globs/packages).

Leon

fawaka at gmail

Jul 6, 2012, 9:34 AM

Post #12 of 35 (242 views)
Permalink

Re: Objects without stashes? [In reply to]

On Fri, May 25, 2012 at 10:20 PM, Ricardo Signes
<perl.p5p [at] rjbs> wrote:
> I proposed this in 2008:
>
> http://markmail.org/message/3wwf7pra3whfks5n

I knew I couldn't be the first with this idea.

> It was very exciting, to me, to have things half-working, but the second 90%
> was problematic. Florian's anonymous stashes were useful, but wouldn't survive
> threaded builds, and the idea of building it all with magic on the stashes was
> grody, to put it lightly.

Which only more confirms my conviction that this should be fixed at a
deeper level.

> To what extent does this sort of thing prefigure Stevan Little work on p5-mop?
> While I'd love to have this feature, we wouldn't want the two to play against
> one another.

This is more of an implementation detail that would should make things
more sane It shouldn't affect the design of the mop itself (though it
should be powerful enough to be able to support the mop).

Leon

rurban at x-ray

Jul 8, 2012, 8:17 AM

Post #13 of 35 (233 views)
Permalink

Re: Objects without stashes? [In reply to]

On Fri, Jul 6, 2012 at 11:34 AM, Leon Timmermans <fawaka [at] gmail> wrote:
> On Fri, May 25, 2012 at 8:47 PM, Reini Urban <rurban [at] x-ray> wrote:
>> Simplier? A MOP will always be more complicated and slower.
>> Our approach is always more general than the tighter OO systems in
>> other languages you are thinking of.
>
> I don't think a MOP has to be slower, in fact I can imagine it being
> faster than what we're using now. Currently we have to deal with lot
> of the overhead due to the mismatch between the kind of semantics
> people want (powerful stuff like a mop) and the building blocks we
> have available to build that (stashes/globs/packages).

Nonsense.
It is slow because it cannot be optimized at compile-time.
stashes, globs and packages are perfectly fine. The problem
is our lack of constness or more compile-time knowledge/attributes.

A MOP is by definition slower. It is a HUGE overhead.
Please do some basic readings what a MOP is.
It can be made faster when the general perl syntax (independent of a MOP)
will allow compile-time optimizations.
Changing over to new keywords will allow this easily.
--
Reini Urban
http://cpanel.net/ http://www.perl-compiler.org/

doy at tozt

Jul 8, 2012, 9:35 AM

Post #14 of 35 (236 views)
Permalink

Re: Objects without stashes? [In reply to]

On Sun, Jul 08, 2012 at 10:17:31AM -0500, Reini Urban wrote:
> On Fri, Jul 6, 2012 at 11:34 AM, Leon Timmermans <fawaka [at] gmail> wrote:
> > On Fri, May 25, 2012 at 8:47 PM, Reini Urban <rurban [at] x-ray> wrote:
> >> Simplier? A MOP will always be more complicated and slower.
> >> Our approach is always more general than the tighter OO systems in
> >> other languages you are thinking of.
> >
> > I don't think a MOP has to be slower, in fact I can imagine it being
> > faster than what we're using now. Currently we have to deal with lot
> > of the overhead due to the mismatch between the kind of semantics
> > people want (powerful stuff like a mop) and the building blocks we
> > have available to build that (stashes/globs/packages).
>
> Nonsense.
> It is slow because it cannot be optimized at compile-time.
> stashes, globs and packages are perfectly fine. The problem
> is our lack of constness or more compile-time knowledge/attributes.
>
> A MOP is by definition slower. It is a HUGE overhead.
> Please do some basic readings what a MOP is.
> It can be made faster when the general perl syntax (independent of a MOP)
> will allow compile-time optimizations.
> Changing over to new keywords will allow this easily.

There is nothing about a MOP that prevents compile-time optimizations. A
MOP that doesn't allow for compile-time optimizations would be a pretty
poorly designed one. There is nothing about a MOP that requires it to be
"by definition" slower.

-doy

rurban at x-ray

Jul 10, 2012, 8:03 AM

Post #15 of 35 (232 views)
Permalink

Re: Objects without stashes? [In reply to]

On Sun, Jul 8, 2012 at 11:35 AM, Jesse Luehrs <doy [at] tozt> wrote:
> On Sun, Jul 08, 2012 at 10:17:31AM -0500, Reini Urban wrote:
>> On Fri, Jul 6, 2012 at 11:34 AM, Leon Timmermans <fawaka [at] gmail> wrote:
>> > On Fri, May 25, 2012 at 8:47 PM, Reini Urban <rurban [at] x-ray> wrote:
>> >> Simplier? A MOP will always be more complicated and slower.
>> >> Our approach is always more general than the tighter OO systems in
>> >> other languages you are thinking of.
>> >
>> > I don't think a MOP has to be slower, in fact I can imagine it being
>> > faster than what we're using now. Currently we have to deal with lot
>> > of the overhead due to the mismatch between the kind of semantics
>> > people want (powerful stuff like a mop) and the building blocks we
>> > have available to build that (stashes/globs/packages).
>>
>> Nonsense.
>> It is slow because it cannot be optimized at compile-time.
>> stashes, globs and packages are perfectly fine. The problem
>> is our lack of constness or more compile-time knowledge/attributes.
>>
>> A MOP is by definition slower. It is a HUGE overhead.
>> Please do some basic readings what a MOP is.
>> It can be made faster when the general perl syntax (independent of a MOP)
>> will allow compile-time optimizations.
>> Changing over to new keywords will allow this easily.
>
> There is nothing about a MOP that prevents compile-time optimizations.

yes.

> A MOP that doesn't allow for compile-time optimizations would be a pretty
> poorly designed one.

Yes. But I miss it in your prototype.
In comparison Damiens perl5i prototype includes it in the design already.
http://web.archive.org/web/20040224135403/http://www.yetanother.org/damian/Perl5+i/class.html

> There is nothing about a MOP that requires it to be "by definition" slower.

Sorry, it *IS* by definition bigger and slower.
Only in our case perl5 this might be not true because our current design
is so poor/halfbaked, that the addition of a MOP might actually improve
performance and expressibility.
--
Reini Urban
http://cpanel.net/ http://www.perl-compiler.org/

chris at prather

Jul 10, 2012, 2:17 PM

Post #16 of 35 (242 views)
Permalink

Re: Objects without stashes? [In reply to]

On Tue, Jul 10, 2012 at 11:03 AM, Reini Urban <rurban [at] x-ray> wrote:
> On Sun, Jul 8, 2012 at 11:35 AM, Jesse Luehrs <doy [at] tozt> wrote:
>> On Sun, Jul 08, 2012 at 10:17:31AM -0500, Reini Urban wrote:
>>> On Fri, Jul 6, 2012 at 11:34 AM, Leon Timmermans <fawaka [at] gmail> wrote:
>>> > On Fri, May 25, 2012 at 8:47 PM, Reini Urban <rurban [at] x-ray> wrote:
>>> >> Simplier? A MOP will always be more complicated and slower.

>>> > I don't think a MOP has to be slower, in fact I can imagine it being
>>> > faster than what we're using now.

>>> A MOP is by definition slower. It is a HUGE overhead.
>>> Please do some basic readings what a MOP is.

>> There is nothing about a MOP that requires it to be "by definition" slower.

> Sorry, it *IS* by definition bigger and slower.

I think I'm going to regret asking this but what definition are you using?

Wikipedia's definition is pretty close to what I've traditionally
always understood a MOP to mean (based on reading Art of the
Metaobject Protocol, Putting Metaclasses to Work, and whatever else
stevan threw at me over the years):

A metaobject protocol (MOP) is an interpreter of the semantics of
a program that is open and extensible. Therefore, a MOP determines
what a program means and what its behavior is, and it is extensible in
that a programmer (or metaprogrammer) can alter program behavior by
extending parts of the MOP. The MOP exposes some or all internal
structure of the interpreter to the programmer. The MOP may manifest
as a set of classes and methods that allow a program to inspect the
state of the supporting system and alter its behaviour. --
https://en.wikipedia.org/wiki/Metaobject

By this (and every other definition I've read) Perl5 has has a MOP
since around the time of a0d0e21ea6ea90a22318550944fe6cb09ae10cda,
because the packages / statshes / globs that people complain about
form a protocol for introspection and altering program behavior. It
just happens that in Perl5's case for the first decade of it's life it
didn't "manifest [the MOP] as a set of classes and method".

There is nothing intrinsic that I can see in this definition that
automatically means that a MOP *must* be "a HUGE overhead", there is
nothing in the definition that says that it must be bigger and slower
than what we have now (packages/stashes/globs). In fact by the strict
definition what we have now *is* a MOP.

So what basic readings on MOPs have I missed?

-Chris

rurban at x-ray

Jul 10, 2012, 8:36 PM

Post #17 of 35 (236 views)
Permalink

Re: Objects without stashes? [In reply to]

On Tue, Jul 10, 2012 at 4:17 PM, Chris Prather <chris [at] prather> wrote:
> On Tue, Jul 10, 2012 at 11:03 AM, Reini Urban <rurban [at] x-ray> wrote:
>> On Sun, Jul 8, 2012 at 11:35 AM, Jesse Luehrs <doy [at] tozt> wrote:
>>> On Sun, Jul 08, 2012 at 10:17:31AM -0500, Reini Urban wrote:
>>>> On Fri, Jul 6, 2012 at 11:34 AM, Leon Timmermans <fawaka [at] gmail> wrote:
>>>> > On Fri, May 25, 2012 at 8:47 PM, Reini Urban <rurban [at] x-ray> wrote:
>>>> >> Simplier? A MOP will always be more complicated and slower.
>
>>>> > I don't think a MOP has to be slower, in fact I can imagine it being
>>>> > faster than what we're using now.
>
>>>> A MOP is by definition slower. It is a HUGE overhead.
>>>> Please do some basic readings what a MOP is.
>
>>> There is nothing about a MOP that requires it to be "by definition" slower.
>
>> Sorry, it *IS* by definition bigger and slower.
>
> I think I'm going to regret asking this but what definition are you using?
>
> Wikipedia's definition is pretty close to what I've traditionally
> always understood a MOP to mean (based on reading Art of the
> Metaobject Protocol, Putting Metaclasses to Work, and whatever else
> stevan threw at me over the years):
>
> A metaobject protocol (MOP) is an interpreter of the semantics of
> a program that is open and extensible. Therefore, a MOP determines
> what a program means and what its behavior is, and it is extensible in
> that a programmer (or metaprogrammer) can alter program behavior by
> extending parts of the MOP. The MOP exposes some or all internal
> structure of the interpreter to the programmer. The MOP may manifest
> as a set of classes and methods that allow a program to inspect the
> state of the supporting system and alter its behaviour. --
> https://en.wikipedia.org/wiki/Metaobject
>
> By this (and every other definition I've read) Perl5 has has a MOP
> since around the time of a0d0e21ea6ea90a22318550944fe6cb09ae10cda,
> because the packages / statshes / globs that people complain about
> form a protocol for introspection and altering program behavior. It
> just happens that in Perl5's case for the first decade of it's life it
> didn't "manifest [the MOP] as a set of classes and method".

Good argument. I didn't think of that.

> There is nothing intrinsic that I can see in this definition that
> automatically means that a MOP *must* be "a HUGE overhead", there is
> nothing in the definition that says that it must be bigger and slower
> than what we have now (packages/stashes/globs). In fact by the strict
> definition what we have now *is* a MOP.
>
> So what basic readings on MOPs have I missed?

Our object system using basic hashes and exposing those as global data
is indeed so general that you can call it a tiny mop.
We can also change the method resolution on the fly by using
mro 'dfs' or 'c3', and next::method.
We have generic functions via UNIVERSAL and dynamic dispatching via AUTOLOAD.

But other basic OO features are not doable:
Stashes not tieable, nor const'able.
We only have global stashes, nothing else.
Methods cannot be private nor protected, attributes neither.
tie and overload cannot solve everything, even if they help enormously
to satisfy the need to do crazy stuff by making the general stuff
slower and bigger.
We cannot have multi methods, multiple inheritance.
We do not support types, function argument nor return types.
We do not have a signature parser in core.
Calling functions is super slow, and I see no way improving this mess.
We are afraid of fixing the basic language features,
but allow easily to come up with annoying, special and slow new
syntax features.
E.g. const my $foo = 0; instead of my const $foo = 0;
attributes are overarchitectured and not usable.
Devel::Declare madness instead of one sane signature parser.
Lots of incompatible signature parsers and not a single one is
good enough to be acceptable to core semantically. The
implementation overhead is also crazy.
Moose with 30MB in memory and a huge startup overhead.

But we consider adding a MOP to core which makes the way our
object framework works adjustable and introspectable.
This comes with a price.

I'm not against it since it allows the basic features to be added finally.
But it's still a little insane.
--
Reini Urban
http://cpanel.net/ http://www.perl-compiler.org/

fawaka at gmail

Jul 12, 2012, 2:37 AM

Post #18 of 35 (237 views)
Permalink

Re: Objects without stashes? [In reply to]

On Fri, May 25, 2012 at 11:36 PM, Stevan Little
<stevan.little [at] iinteractive> wrote:
> I think you might run into a circularity issue with fetchmethod and ref being actual methods (how can fetchmethod fetch fetchmethod?), but this is the compromise of bootstrapping, so perhaps you make this a function call instead, after which you can make a method called fetchmethod that could call it (with some protections for infinite looping of course). We actually do something like this in the p5-mop internals for executing methods [1] but it does get a little messy (and mind-numbing at times).

I was thinking on a much lower level than that, at lowest C level, so
circularity shouldn't be an issue unless an implementation is
implemented in Perl using itself.

Currently method lookup is defined in the core roughly

1) Get stash
2) Lookup method for that stash

I'd like that to change that

1) Get meta thingie
2) Lookup method in thingie.

At first sight, introducing this indirection seems simple. The
complicated part is other places that make assumptions about the
presence of stashes on objects.

> Inheritance can be tricky, so either the vtable structure itself needs to know about it (which is the case with most vtable implementations) or the vtable needs to get locked at some point so that it can flatten out the inheritance hierarchy. Again, we are doing something similar in the p5mop in how we are using Package::Anon [2].

I can imagine. This is obviously something that needs to be thought out well.

Leon

rev.chip at gmail

Jul 12, 2012, 8:09 PM

Post #19 of 35 (234 views)
Permalink

Re: Objects without stashes? [In reply to]

On Fri, May 25, 2012 at 04:47:17PM +0200, Leon Timmermans wrote:
> I hate the way classes/objects work. In particular, I think stashes of
> globs of other stuff is paradigm that fails ...

At the micro change level, how about just allowing arbitrary hash refs as
stashes? Seems like any self-respecting MOP would need that anyway, and
it's a useful feature for anyone doing mixins.
--
Chip Salzenberg

jesse.luehrs at iinteractive

Jul 12, 2012, 8:43 PM

Post #20 of 35 (236 views)
Permalink

Re: Objects without stashes? [In reply to]

On Thu, Jul 12, 2012 at 08:09:31PM -0700, Rev. Chip wrote:
> On Fri, May 25, 2012 at 04:47:17PM +0200, Leon Timmermans wrote:
> > I hate the way classes/objects work. In particular, I think stashes of
> > globs of other stuff is paradigm that fails ...
>
> At the micro change level, how about just allowing arbitrary hash refs as
> stashes? Seems like any self-respecting MOP would need that anyway, and
> it's a useful feature for anyone doing mixins.

On the one hand, any implementation of a MOP that actually works well is
not going to have any interaction with stashes at all (the indirection
of going through typeglobs is unnecessary and just slows things down and
complicates things for no reason - all MOP-based classes would need is a
map of methods).

On the other hand, the core already basically supports this right now,
since nearly every interaction with stashes already is through HV*s,
rather than names (see Package::Anon for how little extra support really
is needed). I don't see any reason why this couldn't be officially
supported with very little effort or downsides.

-doy

rurban at x-ray

Jul 13, 2012, 5:28 AM

Post #21 of 35 (228 views)
Permalink

Re: Objects without stashes? [In reply to]

On Thu, Jul 12, 2012 at 10:43 PM, Jesse Luehrs
<jesse.luehrs [at] iinteractive> wrote:
> On Thu, Jul 12, 2012 at 08:09:31PM -0700, Rev. Chip wrote:
>> On Fri, May 25, 2012 at 04:47:17PM +0200, Leon Timmermans wrote:
>> > I hate the way classes/objects work. In particular, I think stashes of
>> > globs of other stuff is paradigm that fails ...

It works mostly fine esp. for our module system (global names <-> files), but
is awkward with e.g. anon classes.

>> At the micro change level, how about just allowing arbitrary hash refs as
>> stashes? Seems like any self-respecting MOP would need that anyway, and
>> it's a useful feature for anyone doing mixins.
>
> On the one hand, any implementation of a MOP that actually works well is
> not going to have any interaction with stashes at all (the indirection
> of going through typeglobs is unnecessary and just slows things down and
> complicates things for no reason - all MOP-based classes would need is a
> map of methods).

Agreed.

> On the other hand, the core already basically supports this right now,
> since nearly every interaction with stashes already is through HV*s,
> rather than names (see Package::Anon for how little extra support really
> is needed). I don't see any reason why this couldn't be officially
> supported with very little effort or downsides.

Yes. name -> HV* was one of the biggest improvements.
If the HV*s is a stash or on a pad shouldn't really matter.
We should really get rid of these nasty assumptions and name magic
all over the place.

SVf_CLASS maybe? And why HV* when a AV* would also make sense,
esp. performance-wise. With closed/const classes with could precalculate
all method and attribute slots.
SVf_OOK is not needed anymore for HVs as HVs now require always the
hv_aux struct.
And we need to mark const/readonly hashes also somehow to seperate them from
restricted hashes, if necessary.
--
Reini Urban
http://cpanel.net/ http://www.perl-compiler.org/

davem at iabyn

Jul 13, 2012, 5:48 AM

Post #22 of 35 (236 views)
Permalink

Re: Objects without stashes? [In reply to]

On Fri, Jul 13, 2012 at 07:28:14AM -0500, Reini Urban wrote:
> SVf_OOK is not needed anymore for HVs as HVs now require always the
> hv_aux struct.

Huh?

$ p -MDevel::Peek -e'my %h; Dump \%h; each %h; Dump \%h' 2>&1 | grep FLAGS
FLAGS = (TEMP,ROK)
FLAGS = (PADMY,SHAREKEYS)
FLAGS = (TEMP,ROK)
FLAGS = (PADMY,OOK,SHAREKEYS)

--
That he said that that that that is is is debatable, is debatable.

rurban at x-ray

Jul 13, 2012, 6:06 AM

Post #23 of 35 (227 views)
Permalink

Re: Objects without stashes? [In reply to]

I forgot the simple stash logic that every HV with a NAME is a STASH.
No need for a flag to check.

On Fri, Jul 13, 2012 at 7:48 AM, Dave Mitchell <davem [at] iabyn> wrote:
> On Fri, Jul 13, 2012 at 07:28:14AM -0500, Reini Urban wrote:
>> SVf_OOK is not needed anymore for HVs as HVs now require always the
>> hv_aux struct.
>
> Huh?
>
> $ p -MDevel::Peek -e'my %h; Dump \%h; each %h; Dump \%h' 2>&1 | grep FLAGS
> FLAGS = (TEMP,ROK)
> FLAGS = (PADMY,SHAREKEYS)
> FLAGS = (TEMP,ROK)
> FLAGS = (PADMY,OOK,SHAREKEYS)

Yes, each requires that.
In my experiments all my simple hashes (created in the compiler) without hv_aux
fail to work since 5.15, even when not using each. hv_store also
accesses now RITER.
We should create all our hashes with hv_aux already and forget about
the OOK checks.
--
Reini Urban
http://cpanel.net/ http://www.perl-compiler.org/

davem at iabyn

Jul 13, 2012, 6:27 AM

Post #24 of 35 (232 views)
Permalink

Re: Objects without stashes? [In reply to]

On Fri, Jul 13, 2012 at 08:06:50AM -0500, Reini Urban wrote:
> I forgot the simple stash logic that every HV with a NAME is a STASH.
> No need for a flag to check.
>
> On Fri, Jul 13, 2012 at 7:48 AM, Dave Mitchell <davem [at] iabyn> wrote:
> > On Fri, Jul 13, 2012 at 07:28:14AM -0500, Reini Urban wrote:
> >> SVf_OOK is not needed anymore for HVs as HVs now require always the
> >> hv_aux struct.
> >
> > Huh?
> >
> > $ p -MDevel::Peek -e'my %h; Dump \%h; each %h; Dump \%h' 2>&1 | grep FLAGS
> > FLAGS = (TEMP,ROK)
> > FLAGS = (PADMY,SHAREKEYS)
> > FLAGS = (TEMP,ROK)
> > FLAGS = (PADMY,OOK,SHAREKEYS)
>
> Yes, each requires that.
> In my experiments all my simple hashes (created in the compiler) without hv_aux
> fail to work since 5.15, even when not using each. hv_store also
> accesses now RITER.

There's a lot you can do with hashes that don't need hv_aux. At the
end of the following code, OOK is still not set:

my %h;
$h{a} = 1;
@h{qw(b c)} = (2,3);
delete $h{a};
@a = $h{b};
@a = @h{qw(b c)};
$x = exists $h{b};

The main perl-level thing that requires hv_aux is iteration (keys, each
etc); and I rather wonder whether we could avoid creating it for the list
context versions them?

> We should create all our hashes with hv_aux already and forget about
> the OOK checks.

Lets not.

--
I've often wanted to drown my troubles, but I can't get my wife to go
swimming.

nick at ccl4

Jul 13, 2012, 9:06 AM

Post #25 of 35 (234 views)
Permalink

Re: Objects without stashes? [In reply to]

On Fri, Jul 13, 2012 at 02:27:16PM +0100, Dave Mitchell wrote:
> On Fri, Jul 13, 2012 at 08:06:50AM -0500, Reini Urban wrote:

> > We should create all our hashes with hv_aux already and forget about
> > the OOK checks.
>
> Lets not.

If we did, we'd add about 24 or 40 bytes to *every* hash used as an object.
(eyeballing the size for defaults on typical 32 and 64 bit systems)
That feels like quite a high memory cost.

Nicholas Clark

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads