Front page | perl.perl5.porters |
Postings from July 2012
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@gmail.com> wrote: > > On Fri, May 25, 2012 at 8:47 PM, Reini Urban <rurban@x-ray.at> 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. -doyThread Previous | Thread Next