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.  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.

>  > =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 ;-)

>  > =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.

>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.  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."

.greg
-- 
Greg Williams    | If you wish to live a life free from sorrow,
Cnation          | think of what is going to happen as if it had
[EMAIL PROTECTED] | already happened.

Reply via email to