Greg Williams <[EMAIL PROTECTED]> writes:
> At 11:01 +0100 2000/10/02, Piers Cawley wrote:
> >Hmm... I'm really not keen on this idea. Not keen at all. And I can't
> >for the life of me see what's wrong with just making a factory method
> >(or factory class):
> ...
> >Or even simply:
> >
> > package Forest;
> >
> > sub new {
> > my $class = shift;
> > my Frog $local_frog_class = shift || 'Frog';
> > my Frog $frog = $local_frog_class->new;
> > bless({ frog => $frog }, $class);
> > }
>
> The point is that this additional layer of indirection will add a
> (possibly significant) amount of run time to the construction of each
> object.
Err... a minute additional layer of indirection that that hits once at
object creation time. And if you want it to be fast, why are you using
OO. Or Perl come to that?
> As I said in the RFC, "the programmer should not be required to
> circumvent the documented API of a module if the module's author
> will not support the desired changes." On the same note, the
> programmer should not have to resort to solutions to this problem
> that adversely effect the performance of the application.
And you truly believe that the implementation overhead required to
make this RFC fly won't have a runtime cost? Possibly one that has to
be paid by *all* OO programs.
> > > =item * Class Names Would No Longer Be Unique
> >>
> >> A namespace alone would no longer reference a unique stash, as
> >> many stashes might contain code and data for one namespace (such
> >> as 'Frog'). Therefore, a namespace and collection name pair
> >> would be needed to specify a unique stash.
> >
> >This would be nasty.
>
> I agree ;-)
I'll be *really* surprised if implementing something like this doesn't
cause a runtime performance hit.
> > > =item * Method Lookup
> >>
> >> Method lookups would need to examine the collection inheritance tree to
> >> determine which class (that is, in which collection) to dispatch method
> >> calls to.
> >
> >So would this.
>
> I definitely don't see this as a trivial thing to implement, but see
> it as a useful tool to be used in conjunction with object oriented
> programming.
Again, you're adding another dimension of choice to the runtime
despatch mechanism, quite how this is supposed to make things faster
escapes me.
> >Seriously, the problem you refer to is already solved. Check out
> >Design Patterns for a whole host of ways of getting rid of 'tight'
> >coupling between classes.
>
> Lots of the 'problems' that are dealt with in current perl 6 RFCs are
> already 'solved' to some extent. My concern is that the level of the
> solution is currently on the level of a kludge.
Have you actually *looked* at the solutions? Whilst a couple of 'em
possibly count as kludges and some are solving problems Perl doesn't
really have, the majority are elegant and powerful and don't incur
massive performance hits (well, not compared to the costs of going
with OO in the first place.)
> That is, the solution is not as elegant in looks or performance as a
> solution could be were it built into the language. For example, it
> is currently possibly to implement delegation in perl5 (RFC 193).
> However, as the RFC 193 notes, "The module's delegation speed is
> also very slow compared with what an built-in pragma would allow the
> interpreter to achieve."
However, I argue that even without any possible optimizations from the
interpreter, the notational benefits that come from RFC 193 would be
reason enough for implementing it. The same goes for, for example, the
Currying proposal. Yes currying is possible in Perl and has been since
we got closures, but again, the new notation makes it much easier to
deal with and makes the idea usable in a whole bunch of places where
it would have been a PITA before. And again, implementing it doesn't
involve a major change in the architecture of the interpreter, just in
the parser (that's still a big 'just' of course).
I really fail to see what this proposal offers in terms of flexibility
or even notational convenience that can't be addressed by implementing
one or more standard creational patterns. Patterns which have the
advantage of being reasonably well understood in a reasonably wide
community.
And arguing for runtime benefits from something that actually adds
runtime dispatch complexity seems a tad optimistic.
