Front page | perl.perl5.porters |
Postings from July 2012
Re: Objects without stashes?
From: Reini Urban
July 10, 2012 20:36
Re: Objects without stashes?
Message ID: CAHiT=DGNpfZV3QdNM7SpoL67t7n6akynx1zCSdXAku-u-qx_SA@mail.gmail.com
On Tue, Jul 10, 2012 at 4:17 PM, Chris Prather <email@example.com> wrote:
> On Tue, Jul 10, 2012 at 11:03 AM, Reini Urban <firstname.lastname@example.org> wrote:
>> On Sun, Jul 8, 2012 at 11:35 AM, Jesse Luehrs <email@example.com> 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 <firstname.lastname@example.org> wrote:
>>>> > On Fri, May 25, 2012 at 8:47 PM, Reini Urban <email@example.com> 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. --
> 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
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.