Front page | perl.perl5.porters |
Postings from October 2012
Re: What happened to the whole "small core" idea?
Thread Previous
|
Thread Next
From:
Peter Rabbitson
Date:
October 28, 2012 08:59
Subject:
Re: What happened to the whole "small core" idea?
Message ID:
20121027212734.GA7896@rabbit.us
On Sat, Oct 27, 2012 at 04:50:35PM -0400, Peter Martini wrote:
> On Sat, Oct 27, 2012 at 3:58 PM, Peter Rabbitson <rabbit-p5p@rabbit.us>wrote:
>
> > On Sat, Oct 27, 2012 at 09:32:40AM -0400, Peter Martini wrote:
> > > Just a couple of thoughts from my phone, which is why I cut out the
> > message:
> > >
> > > 1. Sub signatures have been prototyped, and quite successfully, on CPAN.
> > > The internal interface could be improved, but the core support is there.
> >
> > This is simply untrue. There has never yet been an implementation on CPAN
> > which concerned itself with the amount of arguments. Nor has there been
> > an implementation which in any way altered the behavior/contents of @_.
> >
> > Yes, you can argue that all this new behavior is scoped and driven by
> > feature pragmas, but to me this argument is void. @_ is a nasty warty
> > semi-global. It can transcend scopes by being preserved on certain
> > jumps. After the original proposal it took you *several months* to
> > consider what happens when the size of @_ does not match the signature.
> > I wonder what you feel about method calls - will all the rules apply the
> > same? What will this do to monkeypatching? This is anything but a sign
> > of a thought through feature.
> >
>
> Actually, it was on my mind the whole time. It worked exactly as my ($foo,
> $bar) = @_ would, which was my stated design goal. I very clearly didn't
> want to go beyond that - and strictness checks certainly counts there -
> because even getting to my ($foo, $bar) = @_ got to be too heated to be
> productive.
In this case I need to retract the part of my criticism that was aimed
at you. My udnerstanding was that the strictness idea originated
partially from your end. Now I understand it was added by interested 3rd
parties, which is now making the entire feature much less palatable to
the "masses". The burden of "you didn't think of that yet?!?!?!" lies
with these 3rd parties.
> As far as the several months goes - well, I don't get paid to do this, and
> spare time is at a premium. When I'd had enough combined free time to have
> a workable prototype put together to address the performance argument,
> which is one I'd considered paramount, I brought that to the group so the
> edges could be polished.
Again - see the above. Also if you were really driven specifically by
performance (which btw is what I love unapologetically) - why not
re-scope the entire proposal? It seems to me all *you* want is to
disable @_ population/maintenance. Isn't it much trivial to make a perl
API hook for that and have the sig-parser part on CPAN? This will both
fulfill your goal AND will collect a massive body of field experience
about "what happens when we muck with @_". If such a feature was
available on CPAN I for one would have totally used it in hot spots on
some of my CPAN projects. Neither am I shy of having a constant-driven
ifdef-like sub declaration in my production code, if this means tangible
improvements of the speed of my function calls while preserving
backcompat.
>
>
> >
> > > 2. The docs in perldoc explicitly suggest, going back to at least 5.8.x,
> > > which is about all I use for now, that alphabetical characters in
> > > prototypes had been banned to allow for this syntax to be added in the
> > > future.
> > >
> > > I agree wholeheartedly on not adding new keywords, but this feels more
> > like
> > > filling a gap then adding something new, using a model for the feature
> > that
> > > has been successful on CPAN.
> >
> > I never said keywords - I said syntax. Not only is your proposal adding
> > new syntax *to the language core*, it does so by hijacking unused parts
> > of a preexisting syntax (prototypes). No implementation on CPAN has
> > attempted this so far.
> >
>
> I know you said syntax, but I do think its important to separate out
> keywords versus syntax, at least for back-compat reasons.
>
> As far as CPAN goes - perhaps nothing on CPAN has done it this way, but if
> we had native hooks at the right spots, I'm sure we would either have
> plenty or a few very good ones. The language docs intentionally leave room
> for it, even if the implementation didn't.
>
>
> >
> > I also feel that I need to remind you that while I am attacking your
> > idea, I am not attacking you. This thread may grow heated, and I do not
> > want you to take away any personal feelings from it. Your implementation
> > skills are way ahead of mine, and your willingness to get something done
> > is remarkable. I have no problems with any of that and I am happy to see
> > your energy being channeled into OSS in general and Perl in particular.
> > However I still think, and will continue to furiously argue, that the
> > goal you are pursuing is at best half-baked and at worst ill-concieved.
> > I just felt I need to write an explicit paragraph about this.
> >
> > Cheers
> >
>
> I don't take it personally, and I do appreciate the feedback. My
> implementation skills are being seriously sharpened by the work I'm pushing
> through here, and I like the heated debates over this feature. It shows
> people care! It's important that if this goes in, it gets done right,
> which means enough people beating up on the corner cases to make sure it
> works in a way that's consistent with the rest of the language, and there's
> certainly been plenty of technical and philosophical discussion on it.
I absolutely agree with you on all points here.
>
> I don't think the goal is half-baked, although I do agree the current
> implementation is. And baking requires heat :-)
Same furious agreement ;)
>
> As far as the goal being half baked - do you mean allowing the syntax 'sub
> foo($bar,$baz){}', or having it baked into core instead of having it
> enabled/disabled as a module?
> I mean, philosophically, do you think it shouldn't exist, that it should
> exist on CPAN as method foo($bar,$baz), or that CPAN should be able to
> alter sub's to allow sub foo($bar,$baz)?
Philosophically there is *nothing* that "should not exist". This is a
ridiculous stance to take. All I am talking about is the impact of
"blessing" something by the act of shipping it such that it works under
`perl -E ...`. Ideally - yes, CPAN offerings should totally be able to
*sanely* (as in easy for the implementor and safely) hook 'sub'
declarations. *Maybe* 'method foo()' with more strictness could be a
stepping stone, but as I said in my reply to Aristotle: The goal is to
be able to have something on CPAN and then lift it into the core
verbatim. In my eye this is the only way to be really sure that
something is a "good idea"(tm).
Thanks for reading!
Cheers
Thread Previous
|
Thread Next