On Friday, 13. February 2009 20:30:24 Larry Wall wrote:
> While taking a shower I refined the design somewhat in my head,
> thinking about the ambiguities in package names when you're redefining.
> By my previous message, it's not clear whether the intent of
>
> multi package Foo::Bar {...}
>
> is to overload an existing package Foo::Bar in some namespace that
> we search for packages, or to be the prototype of a new Foo::Bar
> in the current package. In the former case, we should complain if
> an existing name is not found, but in the latter case we shouldn't.
> So those cases must be differentiated.
Sorry, you lost me. I thought that classes are for implementation
and therefore need to allow re-definition in the sense of open classes.
But aren't packages/modules just for holding names? As such they always
make sure that there is exactly one entity in the scope with a unique
name?
So I would advocate a clear split between the functionality of packages
on the one hand and the implementation orientated classes, roles and
subs on the other. The latter have dispatch and overwriting, the former
are just for uniqueness of names. I know that the current design involves
dispatch to packages but I think that blurs the distinction between
packages and classes. If they are all the same anyway then why have the
module, package and class keywords? This is a bit too much redundancy for
me.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
